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Information system design for administrntiTe systems has 
almys taken enormous time and manpower. Most often, the rea- 
son for this is a communication gap between the user and the 
systems analyst created by an inadequate description of the 
user's problem. This calls for many iterations of the various 
phases of the system development cycle. The problem of reducing 
the time and efforts required for the information system develop- 
ment has been taken up in this thesis. The main idea is to in- 
troduce the computer as a tool in the system development cycle, 

A lot of work is being done in this direction. Some of the 
systemslike Hoskyn' s System, ISDOS and PROTO SYSTEM I - BOTTOM 
PART etc., have tried to use the computer as an aid for the auto- 
mation of the design phase. Systems are also being developed to 
automate the problem acquisition phase. The business definition 
language attempts to describe the functions of the organisation. 



Query-by-exanple, SEQUEL, RIE and PII-IQ attempt to use tuple 
based de,ta selection for the problem description. 

In this thesis we approach the problem by considering 
system description and system analysis phases as of basic 
importance because of the dependence of other phases on these 
tv/o phases. To make the approach practicable, the problem 
acquisition phase is reduced from a function description of 
the user's problem to the description of user's data process- 
ing requirements only. 

A language is needed for data processing systems v/hich 
will be able to describe the data transformations needed by 
the user vd.thout getting into the procedural details of how 
such data would be managed. This language should also be 
suitable for precisely describing the interaction of the target 
inforriation system with its envirora'ient . The basic specifica- 
tion of an information system can be given by describing its 
inputs, outputs or reports, associated timings and the data 
transf omati ons . 

The proposed methodology considers reports as the starting 
point of the information system description. A language is deve- 
loped for describing the reports completely by giving the logical 
structure of the reports. Special features are incorporated in 
this language to describe aspects related to the reporting medium 
or the device. The na.ture of input documents is similar to that 
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of reports. Thus, this language also has features to describe 
input docuaent s . 

The second part of this language incorporates features 
needed for describing data association or the internal pro- 
perties of the required information system. This language 
is based on a block structure approach to provide data oriented 
control structures. Data selection by identifying subsets of 
data by their properties, creation of such subsets of data and 
data generation are developed as special features of this 
language. 

Tine has been used as a special concept. The control 
structure is used to identify different kinds of needs of up- 
dating so that the update aspects can be f'ux'bher utilisf^d. Tine 
three different features of SDL, those of report description 
input docuaent description and data transformation description, 
together can be used to conpletely describe the required 
inf oxxiation system. 

In the proposed nethodo3.ogy, the SDL description is used 
to derive the data needs for the reports. An algorithm for doing 
this has been implemented. Further data needs are identified for 
carrying out various data transformations. The data availability 
from the input documents and from the data transformations is 
also derived. The needs are matched against the availability. 



The netliod for doing this is described. This brings out the 
mssing infoination and superfluous inf omation. 

In real life, systens need nore detailed analysis. Ideas 
have been developed to analyse systen descriptions in SDL, in 
greater detail to point out the shortconings of the description. 
The structure of the language can also be used to collect in- 
f on.iation related to systen design interactively fron the user. 
How queries nay be generated algorithmically to interact vath 
the user for correcting the systen description r.t a detailed 
level has been described. 

In conclusion it can be said that the process of systen 
analysis and description can be aided by tho computer by using 
SDL vAiich is aimed at describing data associo.tions. 



CHAPTER 1 


INTRODUCTION 

With the increased availability of computers, data has become 
a more available resource to control the activity of business and 

If 

this has led to a tremendous increase in the development of manage- 
ment information systems of various kinds* Today, almost eighty 
percent of the total available computing power is being used for 
business systems and therefore they are of primary interest to the 
computer industry. 

In near future potential users of data processing and new 
areas of industrial and administrative applications will generate 
an increasing demand for programming man— power. To keep such man- 
power requirements to a realisable level research is needed towards 
the automation of system design. Development of sophisticated soft- 
ware tools and advacement of design methodologies is envisaged to 
reduce the system design efforts and time. To cut down the system 
development time, enhancement in quality, speed, and ease of develop- 
ment is also necessary. The objective of this thesis is to develop 
such computer aids for system design of management information 
systems. 

1-1 , THE PROBLEM OP INPORMATION SYSTM DESIGN 

Systems like inventory accounting, personnel paso^oll, manu- 
facturing control, accounting, air line reservations, baiiking etc., 
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normuLly constitute the class of data processing systems. Ihe pro- 
cess of system design at the current state-of-art level can be des- 
cribed in terms of five phases: problem acquisition, system analysis, 
system design, system generation or implementation and testing. At 
different stages of development, iterations over seme of these phases 
become necessary due to ambiguity in specifications or due to erro- 
neous analysis, A schematic diagram of this process, given in 
Figure 1-1 siummarises the -various feedback loops in this process. 

In the problem acquisition phase the information needs of the 
organisation are identified. With the help of a dialogue between 
the user and the systems analyst, the information flow in the orga- 
nisation is communicated to the systems analyst. A narrative docu- 
mentation is created and the feasibility of a realistic design is 
studied. 

In the systems analysis phase, with a basic design in mind, the 
data processing needs of the user’s system are identified in greater 
detail and documented by using various kinds of forms specific to an 
installation. What can not be specified in forms is put down as a 
narrative. Quite often, reiteration of the problem acquisition phase 
is needed. These system specifications are considered as the begin- 
ning point for the design phase of this iteration. 

System design phase is "the evaluation of alternative designs, 
generation of program specifications, file specifications, and system 
control requirements in terms of flow charts etc. Most often the 




iigure 1-1. System Development Cycle 








system designer is expected to be the same person as the systems 
analyst due to embedded ambiguity in the specification of the 
system. 
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Phases of implementation and testing require programming and 
operational work. These are noimally the phases that require small 
iterations over the whole process of design due to various types of 
errors that are unavoidable during problem acquisition and analysis, 
An approximate break up of the technical work requirements p’RY-76 ] 


is as follows : 

1 . Problem statement 8% 

2. Functional specification 22^ 

3. File structure and module design ^5fo 

4. Program design, coding and debugging 25 

5. Integration and installation 30?^ 


Attempts ih current research are towards reducing the system 
development time and effort by introducing the computer in the in- 
formation system design loop, in the form of an aid, and further, 
if possible, in the form of a basic designing unit. If the infor- 
mation needs of the organisation are specified in such a manner that 
the specifications have less errors and are more complete in a logi- 
cal sense, then the number of iterations over the system develop- 
ment cycle will be reduced thereby reducing the time and effort 
required. 
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If the information needs can be recorded in a consistent and 
formal manner, then some of the vrork of analysis, design and gene- 
ration can be automated. This vrould reduce the involvement and 
work required from the analyst or the programmer. Automs,ted ana- 
lysis can, in turn, interact with the user and help in creating a 
better and error-free statement of the problem. 

1-2. IBBAS DEVEDOPED lU THE IHESIS 

It has been observed that while recognising the need for a 
computerised information system the user is very clear about the 
outputs and reports expected from the system, A simple reason for 
this is the influence these reports and data outputs have on the 
decision making process besides the other benefits of a computeri- 
sed system. At this stage the user may not have a clear idea of 
the process of obtaining these reports. 

In this thesis a methodology is developed for identifying the 
information needs of the user, making reports as the starting point 
for the systematic analysis of the information needs. 

A language for describing reports has been developed with spe- 
cial features for data generation and fonaatting related to the 
reporting medium, A block structure is followed in the language 
to allow structured development of the report description by the 
user, AH-gorithms are developed to identify data needs from the 
report descripticns . Input documents being a variation of reports, 
the user can also specify the data vai|.ability with the help of 


this language. 
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In business data processing, quite often, the data sets are 
partitioned into a large number of subgroups which undergo simi- 
lar data transformations or processing. A language has been deve- 
loped for describing such data transformations. Handling such 
subsetted data sets is a spcci.'il feature of this language . Algori- 
thms are developed to match the data needs for reports with the 
data availability from input and data transformations. The data 
descripancies, missing data items, and other analysis information 
reported by these algorithms can then be used to correct and modify 
the problem descriptions. 

Algorithms have also been developed to further analyse the 
problem description for design purposes. Procedirres for generating 
queries for analysing have been discussed. 

1-3. OUTLIEE OP THE THESIS 

Chapter 2 of the thesis gives a survey of the research work 
currently being done in this area. In the first part the data 
oriented user-level languages and the form and power of these 
languages is described. Second part deals vsdth the over all system 
design and some cf the implemented systems. Difficulties encountered 
in various approaches have been summaiised. 

Chapter 3 of the thesis gives the basiCi .approach of stating the 
information needs for a system by describing the < re'port rei^uirements. 
Different types of problems encountered in making formal report 
descriptions are discussed. A language is proposed for giving formal, 
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complete and user-oriented report descriptions. Syntax for such a 
language is developed. The semantics of the language is described 
with the aid of detailed examples. An implementation for getting 
data needs from report descriptions, is discussed. 

Chapter 4 of the thesis describes the document and process des- 
cription parts of the system description language. User can directly 
describe the data transformations and data availability in terms of 
documents, so that the data needs and data availability together can 
be used to identify the missing information. A concept of subsetted 
data sets has been developed as the basis of the system description* 
The syntax and semantics of the system description language is des- 
cribed. A generalised update concept and its relation to data cycles 
and data storage is discussed. This concept is incorporated in the 
language for system description. 

Chapter 5 of the thesis describes the different interactive aids 
that can be used for system development if this methodology of system 
description is used. Aids to collect, design and analysis information 
by asking questions from the user are also discussed. 

Chapter 6 of the thesis describes a detailed case-study to 
illustrate the need and the utility of various aspects of the system 
description language. This case study demonstrates the necessity for 
different kind of features in the language and the ease of use of the 


language . 
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Chapter 7 of the thesis summarises the conclusions and discu’sses 
further research work to be done in this area. 



CHAPTER 2 


AUTOMTIOH FOR INEORI'IATIOIT SYSTEMS 

Generalized business data processing was recognised as a re- 
search area in the early sixties [ CDA 59 ] and work was started to- 
wards data system languo.ges and theories of data processing. A 
number of concepts and aids for design and descriptions of such 
systems were developed over the decade [ COU 74 ] . Around 1970, 
work on this problem was also started by various groups at Michigan, 
Sweden, Project MAC at MIT, IBM Research laboratory and others. 

2-1 . DIRECTI OK OP RESEARCH 

Research in this field is focussed on two different areas. 
Automation of system analysis and design is one of these areas where 
a number of systems have been implemented and are undergoing further 
development. ISDOS [ TEI 7l] , Hoskyn's system [rHO 72] , Protosystem I 

[RUT 75 ] are sane of the examples viiich vill be discussed in detail 
later in this chapter. Small commercial softv/are like SMi [ADR 74] 
(system analysis machine), Meta COBOL [ADR 74 ] , COKVSRT etc., are 
available which incorporate the concepts of system analysis and data 
representation in a limited sense. However, these will not be dis- 
cussed. 

The second area of research is to develop the interface by which 
the user can describe his information requirements and information 
transf oxmation; in other words the languages for user descriptions. 


9 
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For the purpose of on overall study, the languages that are being 
currently developed may be grouped according to the basic approaches 
taken. Each group will be discussed in later section of this chapter. 
Query-by -Example, HI-IQ (Hierarchical Interactive Query), SEQUEL 
(structured En^ish QUEcy Languages), FORAL and RIL (Representation 
Independent Language), the language for parameterisation of infor- 
mation systems etc., are based on the relational data base concept. 

BDL (Business Definition Language) is for questionnaire driven inter- 
action for building application models, MAPL and OWL are high level 
languages for interactively building models for the world-of-business. 
Different types of naming mechanisms are used in these two langurges 
to build up relationships, These two languages will be discussed 
along with the Eroto System I. 

ADS (Accxiretely Defined Systems), PSL (Problem Statement Lcn- 
guago), and TAG (Time Automated Grid), directly follow a data proce- 
ssing approach, (These will be discussed along with the other aspects 
of ISDOS, because these have been implemented with ISDOS, Business 
system planning, OSD (Object System Descriptions), lA (information 
Analysis), Systemeering (System Engineering), PIS (Product Informa- 
tion System) are some of the management level techniques, which are 
partially computerised. These will be discussed together, later. 
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2-2, DATA BASE OBIENTED IM&UA&ES 

A nunber of query languages vAiich provide user interfaces for 
logical selection of data from the relational data bases also pro- 
vide some features for making tho queries more readable. The capa- 
bility of these languages is similar to that of DSL-~ [COD 72] 
described by Codd. The reasonsfor discussing these languages in 
the context of data processing are the following : 

(1 ) Data processing systems are now designed with 
data base concepts, using data base software. 

(2) These query languages are non-procedural in 
nature and user-oriented in their form. Data 
processing languages also seek these two pro- 
perties, 

(3) It is generally understood that a combination 
of fairly caiplex queries is equivalent to a 
data processing transformation. For example, 

SEQUEL as a data definition facility for an 
integrated data base[ OHM 75] is required to 
encompass the fuactions of a general purpose 
query language to accomplish many of the tasks 
which were previously reserved for application 


programs 
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Iiimitations of these lexiguages 'will bo discussed by taking 
DSL-f^' as the standard. [Che form, of these languages will be des- 
cribed first and then the capability of these langiriges will be 
discussed together. 

2-2.1 pomi 0? mE LMGUAGES 

2-2.1 .1 SEQUEL ; It has a block structured fora in #iich, 
by using WHERE SELECT and FROM clauses the need for range descrip- 
tion is eliminated and by using a block structure the use of tuple 
Teriables for linking is avoided. This makes a statement more 
natural for a user. SEQUEL is implemented with a model using XEII 
relational memory system with the help of a Pl/1 interpreter. 

2-2.1 .2 HIBBiRGHIGAL lAUQUASE FOR IH TER. 1.CTIVE QU ERIES ; 
HI-IQ used as an interface to Data Base Structure Designer [ G-ER 76] 
is more powerful than SEQUEL due to its hierarchical structure. 

In this the selection is incorporated at every level. Statements 
in HI-IQ are less English-like but the aim of HI-IQ is to make 
staiements to set the environment for data base structure design. 
HI-IQ is mentioned here, because of its power of selection v/hile 
maintaining a fairly hi^ level interface. This is also an implemen- 
ted system. 

2-2.1 .3 QUBRY-BY-EXAt;IPIE ; QBE [ZIO 771 :3 the user 
interface for the System for Business Automation. The langu,age is 
relationally complete. It uses a novel idea of using examples of 
concepts as synonyms of concepts in a local context. The concepts 
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here happen to be domain names, relation names, and instances of 
domain-values which are to be treated as separate lentities. ilso 
the external structure of the language is made up of forms. Ihere- 
fore, instead of v/riting expressions and statements in a foimal 
language the user is restricted to filling up forms. This provides 
ease-of-use and familiarity to user. Nesting of forms is also allow- 
ed. It is obvious that if a process or data to be described becomes 
complex, then description by structirce is easier than description by 
instances or exanples. Advanced form of this instance concept is 
expected to create problems similar to that of natural language pro- 
cessing. 

2-2 .1.4 BIL and.FOBAl : PORAL [SEN 75] and HIE (Represen- 
tation Independent language) [PEH 73] are higher level interfaces 
of DIAH II system, RIl is as povrerful as the other relational lan- 
guages and has more featirres fer derivations, insertions, etc., which 
have been identified as essential for data manipulaition. PORAL is 
the user interface for RIL aiming at allowing the user to represent 
binary and modified binary relation^ips between names-for-things. 

It is still under development. 

2-2.1 .5 A Language for Parameterisatlon of Information 
Systems : Hois larguage [WAN 73] gives a special consideration to 
repetitions, volumes and formats of outputs alongwith the other 
features cemmon to such languages, Por describing foimats of 
reports, line-objects and their spatial placement ore considered. 
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It recognises that specific instances of reports do not determine 
completely the semantics of reports. In a system for automatic 
generation of computer programs [PRY 751 similar difficulties about 
report descriptions have been observed. Further it has been said that 
in report formatting and specifications of messages, continuity and 
availability cf physical space, new page symbols, etc., are to be 
identified. CChese are frequently data dependent. At this point it 
can be added that sometimes a few data items themselves are depen- 
dent on these conditions. Few report specification methods for sol- 
ving these problems are needed. 

2-2.2 CAPABILIIY OF THE LMGUAGES 

To discuss the capability of these languages, in a general way, 
DSL-b.' [cod 72 ] will be considered a familiar representative of those. 
DSL- Cl again is a data base query language. The purpose of this dis- 
cussion is to bring out the basic reason for DSD— a being found very 
limited for data processing desorptions. let us take two relations. 
For example 

Relation PARTS Domains PART /, SUB-PART 
Relation ORDERS Domains SUB-PART, DATE 

Let us also formulate a query: list all the PARTs ^ere all 
the Sub-PARTs are ordered on the same DATE. This obviously needs 
data selection based on subsetted data set ORDERS subsetted for 
SUB-PARTs of the same part i.e., PART /. For doing this, PIPELINE 
concept with seme host language statements will have to be used. 
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In sene other queries one may need in^ge-functions #iich are 
not supplied in the longuage. Also the need for features like 
PIPELIITE and IMAGE fxmetions is there because the language is limi- 
ted to ojoly two quantifiers and These quantifiers one the 

only ones available in the predicate calculus used as the basis for 
DSL- a. A need for being able to partition the data sets into sub- 
sets of tuples and to be a.ble to describe functions of those subsets 
is recognised at this level. This will also be discussed in further 
chapters of this thesis. 

2-3. APPTICATIOI SYSTEM MODELS-QUESTI OMAIKB APPROACH 

An interactive business definition system T HAM 73 is being 
developed to describe user needs by interacting with application 
models in a question anwer mode. The language that is used for this 
approach is BliCi, (Business Definition Language) wrhich forms the user 
interface for ACS (Application Customiser Services) where experts 
can build models of applications by defining program fragments and 
associated questionnaire. BDL is to allow the user to introduce 
options which have not been offered by the model. 

It can be said that this is an a.dvanced and generalised approach 
to what are currently, application packages. Practicability of this 
method depends on how meaningful is representation, referencing, 
and piecing together of program fragments. Work related to model 
building in this approach is yet to take shape. The language BDL, 
vdiich is not yet implemented, has five components as follows: 
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1 . DocTjnent Description Component - DDC 

2. Human Interaction Component - HIC 

3. Device linking Component - DIC 

4. Document ]?low Component - DDC 

5. Document Transformation Component - DTC. 

DDC is used to define the structure and attributes of documents. 

It is also meant for defining the format of the document in terms of 
media that will eventually be used for external realisation. It also 
allows definition of domain types like dollars, date, number etc. 

As DDC is based on a line-item concept (one line of the documents), 
it is suitable for forms and not for reports. Definition of external 
media and its effects are also not generalised. 

HIC, the human iteraction component allows scope for user deci- 
sions in on interactively executing application, Oliis is often needed 
for ’.lanually supervised application, for overriding supervisory 
actions. How HIC can be made a module and not a manifestation of the 
basic development of the application, can be understood only after 
the HIC and the model building process are fully developed, 

DDC is for defining the linkage between the logical media 
described for dociuments and the actual combination of media used. 
Currently this function is being performed by terminal handling systems, 
written by the user, on generalised definition languages. DLC may at 
a more logical level. 
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DPC is the document flow component for defining the basic 
structure of the application. It graphically represents the docu- 
ments and the organisation units called steps, that use these docu- 
ments . 


OEIEE 


, SALES ' 
j OELER 

1 (step) _ 
i i 


(document) 

LEDGm 
(document ) 


• BILLING 

1 (step) ’ 


fcM 

' ■ — 

It deals with steps, paths, documents and fil es. Piles here moan 
sets of documents. Elies are denoted by circles and access paths. 

A step executes vhen all its input documents are present. Accumulo.te, 
stream, copy, join (merge by arrival) are various types of step 
comniands. It is mentioned that processing within steps, described 
latoi as DIO, is oriented around aggregates and therefore input to 
the steps daoiLLd be groups of documents whenever possible (though 
groups may be singleton groups). It also expects the user to do 
explicitely all the linking. Ihis suggests that there are difficul- 
ties in recognising and handling parallelism of steps. Seal life 
document oriented systems have parallelism as a basic property. 

Ohen, it is more the form and not the capability of DEC, that is 


document oriented 
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DTC as the document transformation component is the basic capa- 
bility of BDL. DIG statements are like filling up a form under five 
headings of NAME, DOMIIT, GROUP, FILTER, DERIVATIOl and a heading-less 
space for conditions, whenever needed. The rows actually form part 
of a hierarchy daovm. by indentations which describes repeating groups 
in the output. Under the name cdLumn data items on the output are 
specified. The domain column specifies the name of the group (which 
is the input file name) T\hich generates the data item. Putting TOTAL 
in the name column and one of the ncme column entries in the domain 
column is also allowed. Hov/ this can be linked up with the LDC is 
not very clear. Group column can have entries of data items viiich 
are used for lower levels. This allows very simple subsetting. 

Filter column is for accessing data-itoms from other files (practi- 
cally a means of accessing master reference files), though only simple 
selection can be done on these files. Derivation column is for 
simple calculation and precoded (for example SUM, COURT etc) set 
calculations. 

In DTC, the power of the language has been compromised for a 
form-like appearance. Also, the form filling requires a lot of 
understanding, because of the power of language. At present it can 
not be said as to what extent it gives ease-of-use. 

2-4. HOSKYCT'S SYSTEM 

This system was implemented in 1 972 on an IHVE system using HSL/l 
(Hoskyn's System Language). Th'e system generates COBOL programs 
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fron user statements given in HSL/l . Besides a basic checking for 
undefined elements etc., this system does not perform any design 
activities. It plugs the various names for direct COBOL program 
generation. 

HSL/1 is in the form of three tables, which are called na.trices 
by HSl. These are program/file specifications, record/data specifi- 
cations and condition/action specifications. Linking is dene by 
allotting a column to each program by putting P in the row? for that 
prograra. For files l/O/U etc., are put in the corresponding cdLumiis. 
For simple systems it practically does only the laborious work of 
writing data divisions. The same thing could be obtained by properly 
using the copy option of some COBOL compilers. 

2-5. PROTO SYSTEM I 

Proto System I [RUT 75] is being designed to automate the process 
of 1 rogramming a problem, based on the understanding created by an 
English language discourse, specifically for managanent information 
systems. In this system, the process of writing programs is modelled 
as a sequence of translators from an English language task specifica- 
tion to machine code. The different levels are described as follows: 

TO: Problem acquisition (English OWL) 

T1 : Global problem solution (OHSL DSSL) 

T2: Algorithmic solution (dSSL -»■ CDSL) 

T3 : Computational (CDSL PL/I and JCL) 

T4 : Compilation and loading (PL/l and JCL machine executable) 
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Specifications of the problenij in t erms of data processing 
functions is available at ISSl level and most of the systeo. d.esign 
and optimization of this kind is performed at 12 level. Translations 
of the kind 10 ind 11 are suitable for custom made applications where 
domain dependent terns are taught to the translator (for example 
level 11 ) by an expert who can represent the informational view of 
the problem while presenting it in domain dependent terms. In a 
very general sense, this is also wha,t a systems analyst does. In 
this case the computer aid available to the analyst or the problem 
expert is a system, where world-of -business models can be built. 

Information on OWL is not available but a related language 
MPl [mar 73 ] can be used to discuss the level of model building, 

Ohe basic construct Si-aie rola.tionships, Ror example a-kind-of is a 
relationship which describes objects as characteristics of objects: 

ORDER a-kind-of DOCDl/ENT. Time, activity, data-item, occurrence etc. 
may be some of the basic constructs needed for business models. To 
give an idea, for a very small real life sales system, one may have 
to construct some 4000 concepts before a user's problem in that domain 
may be stated. Levels higher than DSSl may be suitable only for 
package applications. 

Major concepts of DSSL (Detailed System Simulations Languages) leve 
are liming (period), aggregate data objects, computations and initial 
values. Eor computations of subsets, DSSl also gives a few built-in 
functions like SUBSETMAX, SUBSETPITJS, etc. A variable is specified 
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as a conbinoliion of variable nacie, time period and keys. Though a 
vojriable version of current time cycle of given period and that of 
the previous period is allowed, no other versions rre ollov/ed. Natu- 
rally, this is a requirement for update computations. Precedence of 
computations in DSSL is implicit in data relationships and therefore 
user generated subset functions cannot be represented. This is a 
limito-tion for general data processing. Further development of the 
system, hovever, nay incorporate such f acilities. 

At the design and generation level the system has a simulCktor, 
a translator, and an optimiser. Translator transla.tes from the 
compact form of DSSL to more algorithmic forms while maintaining nil 
the design options. It also computes properties like predicates, 
inputs, outputs, precedence, keys of data items as well as computa,- 
tions. Optimiser does the aggregation of computations OvS programs and 
tha.t of data items as data sets. To check the multiplicity and 
existence of data items for estimating I/O costs, the optimiser inter- 
acts with the simulator. Simulator directly executes that part of 
DSSL description (about which an estimate has to be made) on initia- 
lised data items. It collects information about maximum values and 
the probabilities that certain predicates will be true. Aggregate 
system behaviour is obtained by erecuting parts of the system if 
one data item of each type is given to begin the system. 
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At this point it can be said that paxt of the aggregate infor- 
mations, obtained from the simulator, is at tines 'flell known to the 
application user. Interactive aids nay be developed to make the user 
give such information because such simulation nay become a very costly 
and cumbersome process vtien developed to its usable level. It tiay be 
mentioned that optimiser avoids problems of combinatorial order, by combi 
-ling only tv;o processes or two data aggregates at a time. 

2-6. ISIQS : lUlOEMATIOH SYSTEM DESIGN AKD OPTimSATIOIir SYSTEM 

A system for automatic design of information systems [ lEI 71] 
has been developed and implemented on III\ri\i'’AC 1108, IH'I 560 and GDC 
6500 computers. At the user interface it uses Tx\G [ MYE 63] (lime 
Automated Grid) or ADS [NTM 74] (Accurately Defined Systems), At 
the analysis level it has the problem statement analyser, PSA [HEE 74 ] 
with the problem statement language PSD. At the design level it 
has a system optimisation and design algorithm SODA [ IIUIT 71 ] which 
has two modules ALT and OPT for design alternatives and optimisation 
respectively. Glie SODA/ALT generates alternatives by using program 
and file structure algorithms. SODA/OPT has algorithms for optimi- 
sation and performance evaluation. 

TAG is a system design aid which analyses the data item relation- 
ships in the frame of time, by accepting information on an input 
output analysis form. All the input, output, and history data sots 
used in the system are listed along with information about the volume, 
frequency, and ttae of use and the various data iteaaa that constitute 
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the oet. Bata sets can he given priorities within a particul.-r tine 
cycle. TAG gives an analysis of the use of data items in the increas- 
ing time cycle order. This technique v/as originated to consolidate 
the inforoation for nanual analysis. 

The ABS technique uses comparatively more structured set of 
five forms. Specifications for inputs, outputs, history, computations 
and conditions ore listed on separate forms and the linking of do,ta 
items is established by specifying the lino numbers and form or page 
numbers. These forms were also designed for nanual system docunenta- 
tation. As the capability of ABS is limited to element by element 
processing generally used in sequential ^sterns there is no way of 
specifying the structure of the problem and data. 

SOBA/PSL, the language acceptable to the analyser module of 
SOBA/PSA, is a. very high level language for specifying units or modules 
of the system. It has features for naming the parameters of the lunit. 
Por example, units could be inputs, outputs, conditions, process at 
a lower level, process at a higher level, frequencies, and volumes etc. 
It is very suitable for well developed pieces of software or problem 
statement units being handled by different people. It would need 
too many explicit statements about the properties of modules, for 
the first level descriptions of systems. 

Analysis of the total problem is performed by SOBA/PSA by using 
matrix techniques [BAN 65] for analysing data definitions, timings, 
precedences, and vol'ome etc. It also performs more detailed analysis 
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to generate suitatle foms of infornation for design algorithias. It 
gives the error diagnostics but does not aid tho process of analysis 
by directing the user towaxds expected error areas or towards giving 
more infornation for design purposes. 

At the design level j tho alternatives for design of programs and 
files are generated by SODA/ALT and evaluated by using transport 
volume as a perfomoance criteria and using branch and bound methods 
for different CPl'sj core sizes, auxiliary memory and file organisa- 
tions. This approach lea.ds to combinatorial problems. A more heuris- 
tic approach may be more usable. 

2-7 • THEOEBTICAL AWiiLYSlS OF IMPOBM/iTIOIT - for business organizations 

Some approaches to the theory of information systems [ lAE 63] 
are based on the analysis of current functions of the organ! sa.tion. 
Here, it is assumed that 'fimctions' of the firm or the organization, 
must be in action, for it to fulfill its objectives. Defining these 
functions is one way cf stating these objectives. Generic informa- 
tion system design approach jCHA 74] considers inf oxmo.tion needs by 
identifying and analysing all the documents and the data-items tho,t 
are active in the organisation. Systemeering is [lUH 75] another 
direction in lAhich work is being done to analyse the inforno.tion 
needs of administrative systais, by describing the system in tems of 
material flow and message flow. The language in this case uses a 
graphical method. The procedures for doing information component 
analysis and infornation precedence analysis etc. are being worked out. 



25 


At present it can be said to bo a fomal aethod of describing 
the ba.sics of the business functions. The problen of isolating 
the infomation flow for decision naloLiig and orgo.ni so ti oneJ. cai- 
trol and then representing it in on accurate way has yet to bo vrorli- 
ed out in these o,ppro ichos. 

2-8. OOIirCLUSIOITS 

Characteristics and doveloprionts of different systens vioicli 
ha.Te been discussed in the previous sections of this chapter arc 
suina.rized in Table 2.1 and Table 2.2. Description, .analysis, and 
design of information systens for business data processing ,arc very 
mch inter-rel.ited. It has been seen th'it developnent of one stage 
in isolation, limits the capability of other stages. It is felt 
th.at an integrated approach will prove more successful, A few ob- 
servations made at the user interface level nay be roitcrafed as 
follows : 

(l ) Ease-of-uso laay be enhojiced by making the environment 
intern,ctive, and the l.anguage more like English. However, the 
latter nay pose seiiajitic difficulties and therefore atlcast some 
connoiily used associations related to data nc'.y be introduced. 

(2) Description languages should bo more data, oriented in the 
sense of dealing vith sets and subsets of data,. 

(5) Eeports^ messages need noro complote .a,nd detailed descriptions 
as they are the major vehicle of corjnunico,tion between the user .and 


the infomation 
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Systems analysis is more mechanical tha,n itelligent at present. 

It should be recognised that the main 'ehart comings of the problem 
descriptions creep in v^hen the user tries to make a data oriented 
statement while his mental model is still materialistic, for ezample, 
one does not remember while describing sales, to update the store for 
commodities yliich have been sold out though this may not hc.ppen while 
describing stores inventory or accounting. The analysis should also 
guide the user in this sense. 

Techniques of matrix algebra and simulation etc., are currently 
being used for system design. Heuristic approaches may be more work- 
able. Ytoen the user describes different business functions, the 
organisations and the sequence of descriptions tends to be similar to 
the division and arrangement of working in the organisation. Scope 
of changes in the information system in future due to ommission or 
changes in the needs will be very much related to this inherent 
structure and systems can be made more adaptable if the inherent 
problem structure can be put to use in design. 
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TABLJ 2-1 . Systems for Design and Description of Information 

Systems 


System 

Proto 

System 

I 

ISDOS 

Hoskyn' s 
System 

Application 

Questionnaire 

Data Base 

Oriented 

Systems 

Languages 

OWQjMAPL 

ADS, TAG 
PSL 

HSL/1 

BDL 

QBEjPOPAL 
RIL, SEQUEL 
HI -IQ 

Type of 
Language 

Engli sh- 
like 

Data Matrix 

Processing 

Eorm Pro- 
cessing 

DSL- 

System 

De scrip- 
tion 

Model Input, Out- Associa- Model build- 

building put, process tions ing by app- 
using relation- of pro- lication 

binary ships of grams question 

relation- small units files naive 
ships and data 

by mat- 
rices 

Queries 
and data 
manipiila- 
tion 

Method of 
analysis 

Cross 

check- 

ing 

Cross 

checking 

Cross 

checking 

Uot known 

Hot 

relevant 

Selection 
of Design 
Alterna- 
tives 

Simula- 

tion- 

based 

Oombina- 

torial 

genera- 

tion 

User* s 
problem 
state- 
ment 

Mot known 

Hot 

relevant 

Implemen- 

tation 

Yes 

Yes 

Yes 

ETot known 

Yes 


(continued) 
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System 

Proto 

System 

I 

ISDOS 

Hoskyn' s 
System 

Application 

Question- 

naire 

Data Base 
Oriented 

Being 

Develop- 

ed 

further 

Yes 

Hot 

known 

Ho 

Hot known 

Hot 

r el evant 

Basic 
aim 
of the 
system 

Genera- Handling 

lised and gene- 

inventory ration of 

model large 

software 

Genera- 
• tion of 
' small 
data pro 
cessing 
systems 

Generali- 
sed appli- 
cation 
- package 
building 

Data defini- 
tion and 
manipula- 
tion for 
queries 

Existing User's 
problems model 
build- 
ing 

Time com- Limited 
plexity capabi- 
of design lity 

Assembling 
the model 
together 

Tnmi tprS 
query/prob- 
lem formula- 
tion 



Table 

2-1 (continued) 


TABLE 2-2: 

. Data 

Base Oriented Languages 



language 

Query-by -Example 

SEQUEL 

PORAl/RIl 

HI-IQ 

Implemen- 

tation 

System for Busi- 
ness Automation 

System R DIAM II 

EIL only 

Data struc- 
turiser 

Eorm of 
the lan- 
guage 

Eoim, filled in 
with examples 

Block English 

structured like sta- 
query tements 

(in PORAL) 
queries 

(ril) 

Hierarchical 

query 

statements 

j 



CHAPTER 3 


DATA NEEDS FOR INPORIiATION SYSTEMS 

Use of an integrated inf orm..Ltion system introduces a change 
in the information flow within the organisation. Different types 
of information may be available from such an information system, 
such as, usage reports -which help in the execution of f-unctions; 
statistics or status reports for checking and control; study re- 
ports in response to queries etc. How much of such information 
can be useful for the organisation and what it implies in terms 
of diverting information to the machine and how much it costs 
has to be -visualised. Therefore the role of the information sys- 
tem has to be well understood before the inf csrmation needs can be 
described. 

3-1 . IDENTIPICATIOH OP INEOEg'ilATION HEEDS 

Information for administrative control is used in the form 
of documents and reports, whereas, other systems like real time 
systems and control systems, channelise information, more often by 
message display, transducer and converters etc. The methodology 
developed in this thesis is based on the fact that people use in- 
formation in the form of doc-uments and reports of various types, 

Okie primary aim of an information system is to pro-vide such reports. 
If the requirements of these reports are very well known, by way 
of their content, and form, then the user's problem, i.e., the 
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r eqTJlrement s of the information system, can he veil stated. This, 
in turn, may be utilised to find out the processing and data re- 
quired to solye the problem. 

In this vay reports also limit the user's expectations from 
the information systems to whatever may be obtained in the form of 
reports. This forces the user to set the degree of ambition of the 
design cf the system before going into the details of processing and 
design. Gross requirements about the environment of processing, 
types of outputs devices needed, etc., also emerge at this sta;fee. 
Therefore the role of the information system becomes well identified 
at the beginning of the system development cycle. 

A formal description of the problem of information system de- 
sign is needed before the computer can be used for solving it. 
Hfferent methods of such descriptions like model building etc. 
have been discussed in Chapter 2 alongwith the problems associated 
with those methods. A simpler, but otherwise powerful approach, is 
being developed in this thesis where a description of the outputs 
or the reports, will be treated as the basic problem statement. A 
block diagram shown in Figure 3-1 describes the approach. 

Reports can be fully described in a language which will be 
discussed in the next section. Such a formal description is analys- 
ed to find the data needs for all the reports. User can describe 
the input information and the required information processing, i.e., 
the transformations, in a data oriented language which will be 
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discussed in the next chapter. This is compared with the data needs, 
and any discrepencies or missing information is brought to user's 
attention. This process is repeated till a consistent and complete 
description of the information system is obtained. 

3-2. BEPOBT DESCRIPTION LAHGUAG-E 

Data in reports is formally recorded data in the context of 
information system design and is different in na.ture from informally 
recorded reports. Type of such data may be different such as numbers, 
words, pictures, lines, colours, signs, crosses, tick aiarks, seals 
and stamps, punches etc. Special requirements of non-alphanumeric 
data are not being considered while discussing the structure of 
reports. 

3-2.1 STRUCTURE OP REPORTS 

Reports have much more structure than messages, forms, regis- 
ters, and other paper documents. Display of infoimation on reports 
or docimaents has three important aspects : 

(l ) The actual instance of the data, its value and size 

(2) Rame of the data item which can uniquely identify 
the data for the object system. 

(3) Heading or a name for relatively local context. 
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In the form oriented report Icnguages or dfescriptions, such as, 
BEL or ADS, the dichotomy of data and its format is such that it 
tends to restrict at least one of the three, i.e., the dstta instarce, 
data name or data heading. For example, in report description forms 
of Accurately Defined Systems, the relevant data items have to be 
associated with the fomit by linking up of line numbers in the forms. 
In report program generators, control breaks for certain data items 
is the only kind of structure that can be incorporated- In Business 
Definition Language, simple hierarchical structure of data items is 
used. Iherefore a language is needed which has a comparatively free 
formo.t for structuring data definition and format together in a way 
suitable for business systems, 

Hisiness systems have data which records properties of large 
sets cf similar items. A unique name for selected data is not 
explicitely available and therefore it is made up by attaching 
qualifying names viiiich belong to more aggregate levels. For example 
if there are 20 values for OEDEREB-QTJANTITY then one value may be 
expressed by ORDERED-QUADTITY of a CCMJODITY for a OUSTCMER, As the 
heading has limited expressibility, structure is given to the report 
so that a qualifier, common to a number of instances, may be needed 
only once. The user is, often, very specific about the format. 

Bor these reasons it can be said that a language which supports 
hierarchical naming of data will be more suitable for report descrip- 
tions. The language described in Section 4 of this chapter is based 
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on a block structure concept which can maintain hiercxchy of levels. 
This hierarchy is also utilised for effective data naming. Since 
the semantics of the report may not be completely determined by 
specific instances of the reports, it can be described along vsitli 
the structure. Here the semantics of the report means conditional 
appearance and formatting of data-items. For example, if the 
'description' is to be printed only when first time the 'code' 
appears on our output, or when for selected values of data items 
special action is to be taken. 

Example 3-1 illustrates a situation where report is selection 
based. Thought the syntax of the description language vill be in- 
troduced in later sections of this chapter, the example makes use 
of the language. 

3-2.2 STRUCTURE AHE THE MEEIIM OF REK)B!I 

To isolate regions of oomnon qualifiers of data and to get 
speed of referencing for those who are to use the report; continuity 
and availability of physical space, line and colimin spacings, inden- 
tations, new pages etc., are to be identified. The syntactic struc- 
ture of the formatted report is captured by the spatial placement 
of lines of data. Both these are data dependent. Therefore some 
method of synchronising the conditions on the medium of reporting, 
or the output device and the data being put on it, should be available. 
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REPOPlT oh IHVOICE EDITIHC 

PACE 1 i 

PRODUCT 

IHVOICE 

OALCULiiTED 

PRODUCT 

IMXIMUM 

DISCCDHT CaLCEHT 

CODE 

HO 

VALUE 

VALUE 

DISCOUHT 

VALUE 

0513 

10 

53.5 

53.0 


coi'UCTT-i 

0600 

1 



10 

1 2 COmiEHT-? 

0713 

3 

60.0 

65.0 

9 

15 GOIF.IELTT-1 






COIl.IEHT-5 

0613 

6 

23.5 

23.0 


CaiIEtTT-1 

♦ • * * 

s • 

* « • * 

# • ♦ • 

m 


• • * # 

• • 

• • • * 

• • 0 * 


— ■' - “ “ ” 


gOn EACH MY REPORT IHVOIOE-EDIT 
PROM DATA SET IHVOICE-AUEIT: S 

BLAHK 1 2, "REPORT OH IIVOIOE EEITIHG, " PACE-HOT, ffiEE 
NEYf-LIHE, HEADIHG-LIHE-1 , HE\/-1IHE, ITEADIHC-EIHE-2 
POR each OE THE IHVOICE-AUDIT BECIH 

EOR DI SC OUHT- ABOVE-MAX = 1 OR VALUE-DISCiilEPAHCY-COUHT = 1 BECIN 
HEY/-LI1']E, PROBHCT-OODEj JHVOICE-HO 
FOR VAIUE-BISOREPAHCY-OOOTIT = 1 BECIH 
CALCUIATED-VALUE, PROBUCT- VALUE EHD 
FOR DISCOUHT-ABOVE-MX = 1 BECIH 

IL'iZrmJ-DISCODHT, DISGOUHT-VAJ/UE EHD 
C OttlEHT-l 

FOR COll-IEHT-l = BD/JIC BECIH COII'IEIHT-2, ^ 

POR G0MI,IEHT-1 7^ BIAHK AHB COMiAEHT-2 / nH'HTK BECIH 
HEW LIHEj COMI'IEHT-2 EHD 
FOR HEW-PACE BECIH PACE-HUIiBER EHD 
Form HEADIHC-LIHE-1 FROM 1 VALUE "PRODU"- 
-"CT IHVOICE CALCDL/HED PRODUCT M/iXII/IUM DISCOUHT GOMvIEHT" 

HE/iDIHG-2 FROM 2 VALUE "CODE HO."- 

V/HITE VALUE DISCOUHT V/HUE" 

PRODUCT-CODE FROM 2 SIZE 4 IHVOICE-HO FROM 12 SIZE 2 

CALCULATED- VALUE FROM 24 PICTURE 99.9 PRODUCT-VALUE FROM 36 PICTURE 99.9 

I\R1XIMUM-DISC0UHT FROM 45 SIZE 2 DISCOUHT-VALUE FROM 55 SIZE 2 

COItvIEHT FROM 60 SIZE 10 

OVER 
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Spec'.al featiires have been developed in the report description lan- 
guage to sense the cmditions and to control the reporting device in 
a logical sense. This is done by taking paper as the output medium 
in general and incorporating a two dimensional forward control on it 
and associating a cunrent status mth it. 

A simple example of this is vAien a variable numbe r of lines 
appear on an invoice with a three line 'end of invoice' procedure; 
suppose the end- of -invoice port is to be printed at the end of the 
page mless the last ncge of the invoice contains only end-of -invoice 
data the language is shown in Sxanple 3-2i. 

Example 3--2c. 

REPOR T IIWOICES FROM PATA SEP BILltS 

FOR each oust (HER OP BIEL;S BEGIF 
PEW-PAGE j CUSTOI.IER 
FOR each' of the BILL:S BEGIF 

HEW-LIPE, BILL-PO, AMOUNT, END 
FOR LINE-NUMBER ^ 1 BEGIN 

3 LI1®S BEFORE END-OF-PAGE END 
"ML OF INVOICE" 

NEW LINE, "SIGNATURE" 

HEW LINE, " 

OVER 

3-2.3 DATA AND THE REPORTING MEDIUM 

From the report point of view, there are two types of data items 
present on the report. 

1 0 Tliose which are directly obtained from the data base 

2„ Those viiich are dynamically dependent on the ssmchroni— 
sation of format with other data items. 
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A simple excxiple is that of carry-f orward-totals used in 
accounting applications. Such items are included in the r^orts 
to give speed and ease of referencing to the people. To give a 
different ezanple, in listing out customer-vd.se orders, only for 
the first order, the customer name need he printed unless it is 
0 . new page. Such requirements are there to reduce the redundancy 
of information. 

If the format description of reports and the processing of 
the report-information are described in a segregated manner then 
such situations are difficult to handle. In this approach, status 
conditions of the reporting mediim and generation or selection of 
data items can be done together. 

Example 3»3 

REPOEP EMHuOYEE-DETAIL EROM EATA SET EMELOIEE 

EOR EACH DEPT-NO BEGIN 

NEW-PAGE, EEPT-HEABING, EiEPT-NO 
NEW-LINE, ’DEPT-TIPE" ’LEP-CLASS" 

NEW-PAGE, MICE CAEEY-EQRWARB-BALANCE = 0 
EOR EACH NEW-PAGE BEGIN 

PAGE-HEADING, PAGE-NIII.IBER, CARRY-EORWARD-BAL ^D 
EOR EACH EMPLOYEE-NO BEGIN 
NAM, CLASSV -.IDDRESS 
NEW-LINE, BASIC, NET 
ADD NET TO CAERY-EORWARD-BALANCE ^D 
EOR EACH 3 LINES BEEORE END-OE-PAGE BEGIN 

"TOTAL-BALANCE", CAERY-EORWARD-BALANCE END 
EOEMAT PAGE-HEADING VALUE 'EMELOYEE-DETAIL " CAHIY-EOK/AED-BAL 
SIZE S^DEPT-HEADING value "THE DEPARTMEm " NAlffi SIZE 10 CLASS 
SIZE 10 ADDRESS SIZE 10 BASIC PIC 9(4). 99 
NET PIC 9(6). 99 
OVER 
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3-3. PESCHIPTIOW OF THE LACTG-UAGE 

The report description in the proposed language starts by noiaing 
the report and naming a data stream from which the data is to be se- 
lectively put on the report. The user at this point need not visua- 
lise the exact data content of the data stream. It is more for the 
sake of establishing a local reference to a data set which could 
eventually be used for report generation. Also, it need not be a 
defined data set^ as the reports are the starting point of the 
description. The logical structure and the physical format of the 
report are then described in an interleaved manner. The language 
is a free format language, 

3-3.1 EEATUBES ECE STRUCTURE EESGEIITIOH 

The report structure may be developed in a step by step fashion, 

A report may be described in terns of subreports and group names may 
be used for data items which are functionally similar- Eor example, 
EilMINGS : BASIC, D.A., HM etc. Such groups and subgroups may be 
described at a later stage. This is illustrated in the Example 3-4. 

Detailed description is given in the form of blocks and nesting 
of blocks at different logical levels. This facilitates special 
descriptions at the beginning and at the end of a group of data. In 
present report generators a logical level may be created by a change 
in the value of a data item. HK-th this kind of block structure 
different ts^pe of conditions may be used to create a level. Depending 
on the condition vhich created a level different description for the 
report at that level nay be given. 
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Example 3-4. 


BEPORT COINAGE-PAGE PRai PAPA SEP COIN-RECORD 

NEW-PAGE, PAGE-NDIIBER, HEADING-1, GOIN-1 , COIN-2, COIN-3, (n)OIN-4 
I'^W-IINE, C OIN-VALNE-HEADING, COIN-VilLUE OCCURS 7 PIIIES 
POPAL OP COIN-YADUE, 

NEW-IINE, ALL " *' 

OYER 

REPORP DEPP-COIN-RECORD 

mCM PAPA SEP DEPP-COIN-RECORD 

EOR EACH DEPP-COIN-RECORD BEGIN 

COINAGE-PAGE REPORP USING (DEPP-COIN-RECORD EOR COIN-RECORD) END 
COINAGE-PAGE REPORP USING ( POPAL OE DEPP-COIN-RECOED mR COIN-RECORD ) 
OYER 


EOR EACH MONDE 
REPORP COINAGE 

^OM DAPA-SEP EMPLOIEE-CdNAGE 
EOR E/iCH DEPP BEgN 

EOR DEPP 32 BEGIN MAKE PAYPOINP OP Et.CPIOYEE-COINAGE = 1 

EOR. DEPP 40 BEGIN MAKE PAIPOINP OE EMPLOYEE-COINAGE = 2 ETO 

EOR DEPP 61 BEGIN MAKE PAYPOINP OE EMELOYEE-COENAGE = 3 ETO 

EOR DEPP 99 BEGIN MAKE PAYPOINP OE EMPLOYEE-COINAGE = 4 MD ‘ 

END 

EOR EACH PAYPOINP BEGIN 
EOR EACH DEPP BEGIN 

DEPP-COIN-RECORD REPORP USING (EMPLOYEE-COINAGE EOR DEPP-COIN-RECORI 
END 

C CINAGE-PAGE REPORP USING (POPAL OE EMPLOYEE-COINAGE EOR COIN-RECORD) 
END 

COINAGE-PAGE REPORE USING (POPAL OE EMPLOYEE-COINAGE EOR COIN RECORD) 

NEW LINE 
AIL " 

OYER “ 


3-3.2 EEAPURES EOR PAPA SELEGPION 

Eormat of the report nay be dependent on the properties of data. 
In ADS and report generators this is incorporated to the extent of 
control breaks and totals. In our language it is possible to specify 
properties of data in greater detail. Eor example if data item 1 is 
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non- zero only then certain other data items should bo put on the 
report. A more important aspect of data selection, vhich is sub- 
setting of data, Td.ll be described in detail in the next chapter. 

Data selection becomes more important when certain kind of 
processing for data generation has to be described specially in the 
context of reports due to its relation with the reporting medium. 

3-3.3 FEATURES BELATED TO BEPOKPIMG MEDIUM 

Status conditions of the reporting medium or the hardware, like 
HEW-PAG-E, EHD-OE-PAGE etc., can be used olongwith the data conditions 
to format the report. Control of the reporting medixim is also needed 
for formatting for selectiye posntioning of data on paper and this 
nay be described along with the data, items and other processes. 

It helps in making the report description complete and independent. 

3-4. SYNTAX OF THE MRGIJAGE 

Syntax of the elementary form of the language is being given here 

to aid the description given in the above sections. 

<REP0RT> : := HEP0IH! < REPORT-ID > <EETAIL > OVER 
<-DETAIl> "= <STEUCTUEE> < FORPi/lT >| <COPY-STATEIIEM'> 

<STRUCTUEE > : := <DATA-SET-CMUSE><PBDGEDIIRE-EEOCK> 

<EEP0ET-ID> <VAEIAP[LE-HAIffl> 

<DATA-SET-CLAUSE > : := FROM ItlTA SET < DATA-SET-MME > 

<DATA-SET-RAME > : := <VARIAHLE-ITAa§^ail | < VTRIABIE-NAME X TIME-INSTii[TT‘> 
<PEOCEDDEE-EDOCK > ; := <SIMET,E-PROCEDUEE > | 

.pgR<0CBrDITI0N'> BEGIE <PEOCEDUEE-HLOCK> EICD | 
<PR0DEDDEE-BE0CK > <PEOCEDTIRB-EDOCK > 
<SI]V1PIE-PR0GEDUEE> : <REP0RT-H/RDWAEE-PR0GED1IRE> 

<DATA-ITEI4-STEIEG > 

<GAIiCULATI 01ir-STATEIiERT> 

< REP0ET-CA11> 

<C0iroiTI0E> : := <EEPOET-HARDWAEE-OOElDiriONS > 

<DATA-SET-ELEME1TT-SELECTI0E > 

<SIMPIE-DATA-C0in)I TI 0NS> 
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< EEPOEE-CAIiL > ::=< V/iRIAHLE-IIAI/IE > ' BEPOBI |< COPY SP TPjWIP > 

< USIEG-CLAUSE > : := ^IPTY > | USING REEIiACE-GIiAUSE 

< REEL AGE-CLAUSE > : := < REPLACE-CLAUSE > < REEL AG E-CLAUSE > [ 

< ;.LI'HA STRnTG> EOR < /iPHA S'TRIIIG > 

< DATA-LTEM-STRLFG> : := <DATA-ITEM > | <DATA-IPE[,I> < DATA-LTEi:4-SirRIlTG> 

< DATA ITEKL : := <SI]lilPLE-DATA-ITEtI> | <CALCULATED-DATA-ITEM > 

< CALCULATED-DATA-ITEM> : := TOTAL OF < VARIAELE-HAlilE > | 

COURT < VARIAELE-RAEIE> ^ < Vi!JlIABLE-Ml,IE> [ 
MAX < VAEIABLE-RAI'!IE> ^ < VilEIAELE-RAtIE> | 

(ether standard functions nay he added) 

< SniPLE-DATA-ITEJ/^ : := < SIRGLE-DATA-LTEIv^ | <''/U?EAT-. -DATA-ITEM !> 

< SLRGLE-DATA-ITEI(E> ; := <VAEIAELE-1TA1£E > |<LITERAL> [ <0THEE-DI > 

< AEEAY-DATA-ITEI'/D> : := < VARLAELE-RAI.IE > OCCURS < INTEGER > TBdES " 

< CALCULATIOR-STATEf,(IE]\lT> : := MAKE <YARIAELE-I'TA])/1E > =< SIlTGLE-E'iiA~ITEM> 

(assignment ) 

ADD < ADD-CLAUSE> | 

GOKEPUTE < COI.IPUTE-GLAUSE > | 

IRGREtlERT < IRC-GLAUSE > | 

JULTIELY <JCIL-GLAUSE> 

<REPOET-H/iEDWARE-PROCEDURE> : s= NEW-EAGE | NEW-LINE I PAGE | 

SKEE-TO-CHAmEL <INTEGER> | 

SKIP-TO-LINE < INTEGER> 

SKIE < INTEGER > LINES 

AFTER < INTEGER > LINES I < INTEGER> 

BEFORE END-OF-EAGE | 

SET-PAGE <INTEGER> LINES! 
SPECIAL-FOM-STATI OMRM T REPRINffl-LINE I 
END-OF-PAGE ' 

<INGEGER> GOLUI/INS SIZE < INTEGER> 

FROM < INTEGER > | 

< REPORT-HA.ELWARE-GONDITIONS > : := PAGE | NEW-PAGE | LINE; INTEGER > I 

GHANNEL < INTEGER > | END-OF-PAGE | 

< INTEGER> LINES BEFaEE~TiirjL''CFApAGE I 
PAGE-GOUNT < INTEGER >j 

< INTEGER^ ^ < INTEGER > LINES BEFO RE 

< DATA-SET-ELEMENT-SELEOTION> : :=^<lffe^VAL^-^OllDiTioN > jcRANGE-OONDITION > 

1 <UNI0UE-VALUE-C0NDITI0N > j 
<DNIQUE-VALUE-OONDITION> <SEQUENOE > ] 
<EL]MENT-OONDITION > 

< GIVEN-VALUE-CONIfl:TION> ; ;= EACH: < VARIABLE-NAME > = < SINGLE-DATA-ITEM> 

< UNIQUE-VALUE-CONDITION> : := EACH< VARIABLE-NAIffi) >““ 

< ELED-5ENT-CONDITION > ; ;= EACH OF < DATA-SET-NAME > 1 < INGEGER > TIMES 

< RANGE-CONDITION> : s= EACH < VARIAELE-NAI/IE =X< RANGE >_}_ 

< RANGE > : := < RANGE > ,<EANGE> j « < SINGLE-DATA-ITEM > 

« FROM <SINGLE-DATA-ITEM > TO < SINGLE-DATA-ITEM > 

< SEQUENCE > ::= ASCENDING! DESCENDING] SEQUENCE ON < VARIAELE-NAMEXSEQ- 

< SIMPLE-DATA-COHDITION> : :=< SII.CPLE-CONDITION ">y " UENCE> 

< SIMELE-DATA-CONDITIONX LOGICAL-RELATION> 

-< SIIffi’LE-CONDITION> 

<OTHER-DIs PAGE-NUMBER I PAGE-GOUNT I LINE-NUMBER | <F CRMATTED-DI > 
<FCEMATTED-DI> : := <VARIAELE-NAM!> (PICTURE) | SPACE ( INTEGER )_ 
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<100-1 GAL-EEL ATI ON > : := NOT 

<SIMPLE-C CILITION > : := < V/iRIAELE-NAI.IE>< RELATIOKx SINGLE-MTA-ITEM > 
<EELATI0N> ::= >|<| = j NOT = I !$| I > I < 

<EOEMAT> EOEM/E <E(EMAT-DETAIL > “ “ 

<EOEMAT-IETAIL> : ;= <EniE> | < LINE> <EOEI.'[jT-DETAIL> 

<LINE> : := < EATA-REPEEENCE> f: DATA-EOEMAT > | DATA-POSITION 
<MTA-EOS]MT > : := < PICTUEE-CLAUSE> |<VAEUE-CL/iESE > 

<MTA-REPERENCE> : := <VAEIABLE-lIAI-ffi > | 

<YAEIAELE-NAI'.![B-> (<Y’OSITION-IN-EEPOET> )_ 

< POSITION-IN-EEPOET > : s= <INTEGEE> 

< PICTDEE-CEAUSE> ; AS IN COBOL [ SIZE < INTEGER > 

< VAGUE-CLAUSED ; := VALUE ' <LITERAL >| VALUE < TII/E-INSTANT > 

< POSITI ON-CLAUSE > ; ;= EEOM CH.igACTER < INTEGER > EEOM < INTEGER > | 

PROM OOLUMN< INTEGEE > 

< VAEIABLE-NAME> : := <LETTER><REST-OP-THE-NAME> 

< EEST-OP-THE-NAME > : ;=< LETTEB> j <DIGIT> [<REST-OP-THE-NAME><E?EST-OP-THE 

NAJ/E > 

<INTEGER> ::■= <DIGIT><DIGIT>< INTEGER > 

< DIGIT > : s= 1/2/ .. . / 9/ 0 

<LITERAI> ::=/ <ALPH/i-STEING > " | filL "< ALPHA-STRING > " -NON-EDANK 

BLANK I ZERO | SPiCE" '[ SPACES I ZEROS |<LITEEAE>^ -<iITEIlAL> 
<ALPHABET> ;;='pTJ"B |C[ , ... | <DIGIT> 

< ALPHA-STRING > : := < ALPHABET >|ALPHABET> < ALPHA-STRING > 

<LETTEE> ::= A] B I C| ... | Z 

3-5 . IMPLEBJENTATION POR DATA NEEDS PROM REPORTS 


Prom a report description giyen in this language, data requirements 
can be derived. A subset of the above syntax has been implemented, using 
a software package to generate the processor. The syntax is described 
in a prescribed way. The semantics is described in the form of COBOL 
procedtires to be executed for the corresponding grammatical entities. 

The software package generates a COBOL program, incorporating the given 
semantics and syntax, complete with a generated scanner etc. Once 
the report description is found to have correct syntax the data needs 
are derived by going through the hierarchical relationships between 
various data-items. Data-items having constant values or values • 
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generated in the course of the developnent of the report are dropped 
from the analysis. Do.ta needs are described in the form of relations 
giving keys and attributes. Various d,ata-i terns having the same keys 
for a unique identification are put as attributes in the same relation. 
Data-itens occuring as keys for some attributes may themselves be 
attributes in other relations. 

Here, attributes a.re those data-items -vdiich are to appear on the 
report. Keys are those data-itens which are used to select and iden- 
tify relevant values of attributes and data-items, at various levels, 
from a large set of data. Data needs for all the reports can then be 
analysed together. The part of the program which ms input to the 
package is given in Appendix 1 

Mien a suitable system software and configuration is available this 
implementation can be easily modified to change the input to inter- 
active mode. In tha,t case the errors can be pointed out and corrected 
on the spot. The output can be presented to the user in a more readable 
way by naming relations using keys. Dor example 
Eelation : 01; keys : CUSTOSilER; attributes ; mm, ADDRESS 
Eelation ; 02;keys : COMIODITY, COST-attributes : SIZE, COLOUE, EEIAHD 
Eelation display; 

CUSTOJEE-DETAII (MIIE, ADDEESS) 

OOMODITY-GOST-DETAII (SIZE, OOLOUE, BEAID) 
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3-6. OOICLUSIOH 

In conclusion it can be said that identifying user's information 
needs is the first step towards informtion system, design and analysis. 
It is very important to set the scope and the necessity of the data 
requirements. By identifying the reports that will be expected from 
a, system the user implicitly states the scope of the required system. 

If the reports can be described in clear and precise may at the user's 
level then the basic data needs can be derived. User has familiarity 
with reporting and if an easy-to-use languog:e vd.th good description 
power is available then a specific start can be ma.de towards informa- 
tion need identification. 

Once an interactive report language processor is available it can 
be extended to help the user in formatting the reports and it can help 
the ^stem analyser in interpreting user's needs in greater detail. 

Ihe report description method developed here has a very special 
advantage of not being a language in isolation but it identifies with 
the further development of a user level data and document description 
language . 

It also has special features where reports which have to be 
related to the reporting mediirm. or the reporting hardware can also 
be completely described. 

Hie data selection feature can be extended. Hor example arithmetic 
expressions on data items may be used for selection within the basic 
structure. Heady made features may be increased or reduced to get ease 
of description without curtailing the power of description. 
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DATA DESCRIPTION FOR IlWORJfADION SYSTEDJS 

There are many approaches to descriptions of information trans- 
formations required for the target information system. In the model 
building approach the user has to b\aild up concepts about actions which 
constitute the real life system. The user, in general, may have to 
build up a very large number of concepts and for handling real life 
systems this method can become very cumbersom. In the questionnaire 
approach a generalised model is developed for the user and a support- 
ing questionnaire, pertaining to the problem area., interacts with the 
user to make the necessary changes for adapting the model for the 
user. This method can be used for highly specialised applications. 

Also to assemble the system again, in the light of the change initia- 
ted by the user is not alvinys possible. In this chapter a different 
approach is proposed for generalised information system descriptions. 

To describe an infonaation system it is not necessary to describe 
all the functions and the entities of the organisation. Information 
system has a specific role in the organization which is that of selec- 
tive data handling. Generally a well structured description of the 
involved data is not available. A purely non-procedural description 
of data only in the foim of a set of predicates or properties is very 
diffic\xlt. The user can, however, give a description of how he can 
get what he wants through repetitive selection of data. In other words, 
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the user can describe the reqiaired information system by giving one 
logical design or statement of data processing. Hien, any descrip- 
tion j T/hich can give rise to equivalent data transformations can 
be used to describe the system and to generate technical designs of 
the system. 

Information systems which are data processing oriented and do 
not necessarily have a library-like function deal with few different 
types of entities and a loxge number of functions related to such 
entities. Such functions give rise to abstract concepts as properties 
of these entities. Por example SALES and COSTING, are concepts which 
are generated entities and are entities formed by data associations. 
Therefore instead of clear cut properties and concepts there are mainly 
data-associations to be described. 

An additional problem exists due to large cardinality of data. 
Eifferent occ^lrrences cannot be provided with names. Therefore, ins- 
tead of directly addressing data, data selection has to be used to 
limit the scope of names in a local sense. For example, data about 
STUDENTS with GEAEE = 9 may be selected for the purpose of describing 
other properties for these STUDENTS System does not maintain different 
names for selecting students with different grades. 

4-1 . STHUOTUEE OB' DATA THANSEOHMATION 

In describing infoimation transf omations, there may be calcxila- 
tions, groupings, assignment or conditions. Data can be visualised 
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in the form of tables ^iiere rows represents the entities or concepts 
and columns represent the properties. For example, in conventional 
sequential systems there ore fields and records. If there are a large 
number of entities and a small number of properties there are more 
rows and few columns. Entities are divided into classes and aggregate 
or overall properties of such classes are derived. For example, 
total quantity of order for a commodity may be derived by aggregating 
all the orders for the commodity. The divisions into such classes is 
done according to properties or the values of the columns. If a 
property can take a large number of values then such classes are again 
large in number and can not be identified by names. For example, if 
order's have two properties such as TYFE and CUSTOMER-NAIIE of ORDER'S. 
TYPE can take values "TEI/CPORARY" or "PERlvIAREEfT" and CUSTOKEIR-NAME can 
take any value from a set of (say) 100 names. Then based on TYPE, 
order's can be named as TET'rPOEARY-ORDEE ' s and PEEIMEEKrT-ORDER's. Bcased 
on CUSTOMM-HME, no such names can be given even if name-wise sets 
have to be referred to. Therefore, it becomes necessary to have two 
type of features in an information system description language. One 
is that of subsetting the entity set into classes. The other is of 
being aHe to perform aggregation of information or of describing 
functions of subsets. 

However, the functions cf subsets are generally describable by 
using simple calcul rtions. Aggregation of information is not like 
that of statistical processing. The difference is there because the 
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inf oriiio-tion developed by the information processing system is normally 
used by people at different levels in the organisation. Miereas, 
results of statistical processing are normally used by small groups of 
trained people, 

4-2. DATA SELECTIQg AMD SUBSETTIH& 

Data selection and data subsetting are two features vAiich have 
been incorporated in the language described here. Depending on the 
values of a property, a set may be divided into classes which are 
functionally similar. Dor each value of that property one instance 
of the class or the subset of data is generated. This is done by 
using "EACH" function. These classes have to be identified or made 
available for generation of aggregate information and for further 
data selection. Dor example, once the STHDEHT's have been divided 
into classes according to &EADE, then value of CRADE can be used to 
identify the subset of students in the GRADE. GRADE becomes a sub- 
set property. This is achieved by using a block structure. A block 
is a sequence of procedures to be done on all sets viiich are input to 
the block, considering one set at a time. The procedures ma,y be of 
the follovri-ng type - 

(l ) Data subsetting procediores 

( 2 ) Data selection procedures 

( 3 ) Data generation procedures (data generation by calculations 
and assignment). 
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4-2.1 DATA SUBSETTIHG PRQCEDUKBS 

The basic tool towards the aggregation of procedures is provided 
by the data subsetting procedures , A subsetting procedure operates 
on a set of data. If the set is input to such a procedure the vdiole 
set becomes available to the procedure at a time (conceptually) though 
the procedure may operate on elements one by one. The procedure out- 
puts a number of subsets each having some elements. It also attri- 
butes seme properties to each subset. Each property has one value 
for one subset and may also be used to further identify the subset. 
Such subset properties then became global properties at subset level 
a3ad in concept are no more associated with the elements of the subset 
on an individual basis. 

To be able to operate on these subsets a number of any kinds of 
procGdures<St:ransf ormations may now be written in a block at a level 
lower than that of the subsetting procedure. Eor these procedures the 
subsets are made available (one subset at a time) along with all its 
elements. These procedures may use only subset properties and not in- 
dividual element properties unless the subsetting has been done to 
an element level. 

Examples : 

EOE EACH OEDER-EO ORDER :S 

EOR EACH OE ORDER :S 

EOR EACH ToRDER-CTO. ORDER-DATE ) OT ORDER :S 
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The above three examples, subset the set of all ORDER'S into 
classes of ORDER’S, v/ith same ORDER— WOs, having ORDER— ITOs as the 
class property and so on. 

4-2,2 DATA SELEOTIOIT PROCEDURES 

Once a subset has been generated with some subset properties 
these subsets may be selected by describing conditions over set 
properties. A simple example is given in the following: 

EOR ORDER :S BEGIH 

EOR EACH ORDER-NO OP ORDER :S BEGIN 

POR ORDER-NO = 1 0 BEGIN NO-ACTION ^ 

POE ORDER-NO NOT = 10 BEGIN 

COUNT ORDER'S ^ NO-OP-ITEtflS 
POR EACH OP ORDER :S BEGIN 

MAKESHORT-QTY = ORDERED-QTY D HECEIVBD-QTY 

END 

END 

SUM SHOET-QTY OP ORDER :S ^ REQUIRED-QTY 

CREATE INVOICE (NO-OP-ITEHIS, REQUIEED-QTY, ORDER-NO ) 

END 

The sequence or procedures isiiich constitute the block at the next 
level may operate only on those subsets which ore selected by the 
procedure creating the block. Prom one class of subsets only one sub- 
set may be used by procedures- It is implied that procedures will be 
repeated on each subset of the class, separately, disregarding aiiy 
sequence in which these subsets may bo present. More complicated selec- 
tion procedtires ma^y be described using the data and other classes of 
subsets that may be available for a procedure according to the context. 
The context is further described in Section 4-2.4. 
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4-2.3 DATA 'GEITEKATIOCT PROCEDURES 

There are various kinds of data generation procedures. KLeinent 
oriented procedures have sinple calculations , assignments and condi- 
tional assignments on different properties of elements. One eleraent 
of class is available at a time for these procedures and one element 
may be generated at a time. An element may be a singleton element or 
a subset. Tftiatever is being treated as an element should be available 
as an element at the level of the procedure, i.e., a procedure has to 
be preceded by relevant subsetting procedures. 

Other than the element oriented procedures there are set functions 
which operate on a subset. Odiese may not take the subset as an element 
with only aggregate subset properties but may treat the subset as a set 
of elements. Por built-in set functions like SUM, ITUMBEE, ALICCATE, 
GOIMT, MIN, MAX, EIEST, LAST, K-TH etc., the set is treated like a 
block box. User-written set functions are very often needed and 
Examples 4-1 describes one such case. In Chapter 3> Example 3-3 also 
describes one such case. Here, the subset is not treated as a black 
box^ but the elements are created, ordered, and processed for aggregation 
at the element level as well as subset level to define such user-written 
set functions. 
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EXAIvIPLjjJ 4-1 

(Running profile of orders, receipts and amount for customers) 


FOR CUSTOTIEE-ORDERsS EEGCT 

FOE EACH CUSTOMER-lIO OF CUSTOMER-ORDER : S BECIl 


EIJD 


MAKE DEIIVEEED-QUAMDITY, OEDER-TO-DATE, AMOUET, ORDEE-SEEIAL- 

EO = 0 

FOE EACH OF CUSTOMER-ORDER :S, SEQUMCE DATE, ASCEHDIE& BEGIN 
INCREASE OEDEE-SERIAD-IO BY 1 

INCREASE OEDER-TO-DATE BY OEDERED-QUANTITY ^ CUSTQIER- ORDER 
MULTIPIY RECEIVED-QUANTITY OF CUSTOMER-ORDER m PRICE OF 

CUSTOMER-ORDER GIVING VALUE 

INCREASE MOUNT BY VALUE 

CREATE CUSTOMER-OEDER-STATUS (OEDER-SERIAL-NO , ORDER-TO-DATE 

AMOUNT; 

DATE, CUSTOIffiR-NO = OUST CMER-ORDER ) 

END 

MKE FINAL-AMOUNT = MOUNT 

SUM RECEIVED-QUA.NTITY OF CUSTOMER-ORDER M DELIVSEED-QUMTITY 
CREATE CUSTOI€ER-BILL (MOUNT, DELIVEEED-QUANTITY; CUSTOMER NO 

= CUSTCMER-NO OF CUSTOMER-ORDER ) 


END 


In the example given above, AMOUNT is 
an aggregate property for a subset of all the customer orders for one 
customer vihich is created by a user written procedure. ORDER— TO— DAi.TE 
for running order status is an element property Yhich is created by a 
user written sot function (i.e., agreegating a property of earlier 
elements in the set). 

In general, a set property at the higher level is always available 
for use alongwith the element properties at the lower level because the 
element belong to the sot. Therefore, T/\ha.t is a subset for a hi^er 
level is a set for a lower level description. If a set property is 
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updated at the elenent prooessing level, then at set level it implies 
a generation of a new property. 

4-2.4 DATA MMLm AHD BIiOGEI STRUCTURE 

Data naming, v/hich is based on a meaning for the name (in accor- 
dance with the context), makes use of the block structure. To begin 
with at is assumed that there is a database containing all the rele- 
vant data sets and their versions. The sets vihich are being consi- 
dered for the data transformation, are selected. A particular version 
of these sets nay also be selected, Dor example - 

DOE ORDBEjS, CUSTaffiE:S, TE/1TSACTI01T;S 

An s with a shows that a number of elements ccnstitute the 
sot. This set is available for processing as one subset containing 
the whole set with only one set property, (or the subset property) 
the property being its name. Therefore, at this level it is selected 
by explicitly giving the name. The very first procedure will naturally 

be a subsetting, because it is not attributed any properties at this 

/ 

level which are identifiable. At level one any subsetting procedure 
can take one set as input and a number of subsets or classes can be 
created as output. The number of classes generated may be only one or 
more. Suppose a function subsets one set into three, being that of 
OEDER:S, The meaning of OEDEErS will be altered as followrs - 
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ORDER :S, CUSTOI/l[ER:S BEGIF 

ROE EACH ORDER-FO of ORDER :S BEGIN 

RQR each CUSTCIffi!R-TIBE OP CUSTOIIERrS BEGUN 
Conment : meaning at this level 

CUSTOMER : A sot of customers with a set property 
customer-type, identifiable by type 
ORDER : A set of orders vith a set property 
order-No*, identifiable by number.. 

Any predicate or description at tlxis level will be 
true for all such sets individually. 

Procedures at the next level will be repeated for all such sets. 
This gives rise to a control structure for implied repetition for 
different sets. It may be observed that like we have PERPORM, DO, 
IP-THEN-ELSE, DO-IHIIE, REPEAT and CASE etc., as eonti'ol structures in 
programming langu<ages, fcr controlling procedures, data transformation 
languages need data oriented control structures for two reasons - 

1 . Commonly used structures for ease of description ; 

2. Basic structures, to give the power of control. 

Example 4-2 shows' ;transformations involving a number of data sots 
and E:-ample 4-3 shows a bills-of -material description to illustrate the 
update needs and capabilities. Normally the repetitions are due to date 
cardinality, but in Example 4-3 they are due to data-values. 


Exauplos 4-2 and 4-3 are as follows: 


t 
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Em'JPLE 4-2 

EOll Tla'iNSACTI'^NsS, lI/xSTERsS, EREGE-iaASITEIliS LEG-IN 
POn E/iCIi OELEn-NO OP TEA1TSACTI-''1T,:S LEGIIT 
""POTi IP.STER (ONDEIL-NO = OIIDEH-NO OE lai'J-ISACIIOll) EEGIN 
EOB i'L'lSTEB PISSENI BEGIN 

ADD QUANTITY OE EGUISACTIOIT TO QU/JTTITY OE ILlSTEB 

GIVING NE^/T-QUANTITY 

UPDATE MSTEB (QUANTITY = NEU-QUMTITY) ETO 

EOB CODE OE TR.'\1TSACTI0N NOT = CODE OE I'lilSTER BEGIN 

EOB EBBOR-IfeSTER (OEDER-NO = OEDEB-NO of 1-EiSTER ) 3EGCN 
UPDitTE LRSTEB (rBIiSON = BE/\SON OE EBBOB-iaSTEB) END 


(One transaction per order-no is an integrity 
constraints, here) 


EZAilPLE 4-3 


EOB PART;S BEGIN 

E^ P/BT-NO OE PABT = 137 BEGIN 

CREATE SUB-P/JIT (= AIL OE PABT) END 
OVEE 

E_^ SUB-PART ;S, PABTsS, SU3-PiUlT-NO : S BEGIN 
TOE EACH OE SUB-Pi\ET BEGIN 

EOB STATUS OE SUB-P..ET = "ELH-ENT/iBY" BEGIN 
CREATE BASIC-P/RT (= All OE SUB-P.ART7~M) 

EOB STATUS OE SUB-P/iET = "ASSETELY" BEGIN 

EOB SUB-PAET-NO (Pi\EENT-P/iRT-NO = PMT-NO OP SUB-PART ) BEGIN 
EOB BACH SUB-P/JIT-NO BEGIN 

EOB PART (PTBT-NO = PABENT-PABT-NO OE SUB-P/iBT-NO ) BEGIN 
ADD SUB-PART (= AIL OE P/iBT) 

END 

OVER 


To show the compactness of description, sone exnnples of 
data base queries are being talsn in the following. 

Query 3.11, [COD 73 ] 

Eoi' each project, obtain as a triple, the project nunber, 
project name and supplier location, for all suppliers viiio supply 


that project. 
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rtiiW&E PROJIDT J 
BANgE SUPPLIER S 

RANGE SUPPLY Z SOME , , 

J.NAME, S.L0C):(J.J# = Z.j/X_y(z.S/ = S.S/) 
EOR PROJECT ;S, SUPPIIER:S, SUPPLY ;S BEGEN 
PQR EACH PROJECT BEGIN 

EOR SUPPLY (j / = J / OE PROJECT) BEGIN 
EOR EACH SUPPLY BEGIN 

EOR S/ OE SUPPLIER = S / OE SUPPLY BEGIN 

CREATE W(J/, NAJ'/EE = ALL OE PROJECT; LOG ' 
LOO SUPPLIER END 

OVER 


ProLlen 

Query 3.10 [ COL 71 1 

Give nones and locations of all suppliers, each of whom supplies all 


projects. 


RANGE SUPPLIER S 
RANGE PROJECT J ALL 
RANGE SUPPLY Z SOME 
GET w(S.NAIvIE, S.LOC) : (S.S/= Z.S/ 
EOR PROJECT tS, SUPPLIER :S, SUPPLY ;S 
COUNT PROJECT ;S AS NO-OP-PROJECTS 



Z.J /= J-J / } 


EOR EAxCH OE SUPPLIER :S BEGIN 

EOR SUPPLY (S/ = SJW supplier) BEGLN 


COUNT SUPPLY :S ^ NO-SUPPLIED 

EOR NO- SUPPLIED = NO-OE-PROJECTS BEGIN 

Cp-RAtR w(NAME, LOC = ALL OE SUPPLIER) END 


OVER 


It can be easily shown that operations of union, itersection, 
difference, projection and restriction, as defined in the relational 
algebra can be easily described using this approach. 
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4-5. gOITCEPT OP UP^TES IN DATA PROCESSING 

In a general sense a data processing system constantly updates and 
processes data. Updating is a procedural concept. In an attempt to 
mrice systom. descriptions more declarative and less procedural orientation 
of the language should be such that update is used as little as possible. 
Iho situations under which an update is used, can be visualised as 
follows : 

1 . ELenentary data item updates 

2. Entity set updates 

5. Property updates for entities 

4. Data, set ujjdates 

The essential typo of update is that of change in the value of the 
properties of a real life entity like customer or a conmodity, about 
v/hich the information is kept. Other kinds of updates found in data 
transformations are due to time cycles, data cardinality or cycles of 
processing. In general, on update cycle may be present in a data 
transformation description as given in the figure below. 



PROCESS ECEUPDATIIGA 
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fach a description does not make clear why the process has 
been described as an update. It just describes that PI, P2 and P3 
arc three processes operating on A, 3 ord C and they together fora a 
cycle. In <an attenpt to bring out the need or the reason for update, 
so that it can be utilised for further analysis and design, different 
constructs are used for different kinds of updates. 

ELeacntary data item updates, like QUMTIIY QUAIWITY + AiffiMIElTT 
are used in data, transformation descriptions. These are basically 
rociuirod to construct n-ary operations (an operation involving n 
da.ta items) using binary arithmetic operator, Por example, BILL 
TOTAL = ORDER 1 + ORDER 2 uses a bin.-ry addition operators. Eor seven 
orders, .a. ready J'liadc n-ary operator SUIi can be used SUM ORDER :S AS 
BILL-TOTAL. We could also have BILL-TOTAL = ORDER-QU/ITTITY * RATE- 
OE-ORDER. In this case a BILL-TOTAL for seven ORDERS vill be obtain- 
ed by updating it for every order, such as, BILL— TOTAL BILL— TOT/iL + 

ORDER-QUAHTITY * RATE-OE-ORDER. Such updates are described by using 
constructs like ADD AICElTDEEffiNT TO QUANTITY, INCREASE QUANTITY BY 
Al'iUMDlCENT etc. Some n-ary cixxstructs like SUIJ, COUNT, NUI.CBEE etc., 
are also defined, to na.intain the ease of use. 

liitity set updates, for example, updated customer set after 
deleting selected customers, are hajidled by ADD and DELETE. This 
avoids update at a description level and makes it, a purely data 
processing level function. Data set updates for removing obsolete 
data from data sets and adding new data to data sets (for example keep- 
ing data about weekly orders) are also made implied data pro- 


cessing functions. 
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U'-idatcs for properties of entities and addition and deletion 
of entities ha.ve t d be given by the user. Data processing oriented 
updates are not a p-rrt of tlio description. In this way, descriptions 
becocio less procedural and user description remins a.t a. system level, 
Wiis helps in understanding the updates and their needs. 

4-4. AS A SYSIHI COHOUPI 

Ihe data processing systems being considered here are ba.tched 
or clocked systems luid not real tine systems. In such systems, sets 
of data are collected over preconceived time intervals. Punctionally 
similar data, occuring at different points of time, may be identified 
by the associating a diiaension of time vd.th data. Time is required 
as ;an integral system coicept for the following reasons: 

1 . i\ll systems have, as a natural necessity, functions linked 
with some or ihs other tiiio aspect. Any description of the system 
cannot avcid referring to time. 

2. Tine ncy be defined as data type in the system because it 
has p. very standard usage and a very complicputed data type having 
lot of sub-types otc*, and complicated naming conventions. If the 

user has to describe the data type in the course of the description then 
a lot of information about the structxnre of the system gets disintegrated 
and remains no more available for the purposes cf analysis ojid design. 

For ex.aQple, suppose there are OEIiEfis for each day of the week, 

Ihere is a data item DAY-OF-OBDER. A data transf crmation description 
may compare DAY-OF-OEDER with the DAIE-OP-EUl'T giving a detailed matching 
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procedure, extrc,ctirjg tlie HAY from the HATH and then couporing the • 
two date, items. If c, facility is given for directly using the HAY 
of a HATE or for declaring HAY-OE-OliDER c-s a special da.ta item 
which identifies the vireelcly ORDER’ s VTith the respective days then 
this infornation can he used to analyse the data and structure it. 

3 . The storage of data in the system depends on its life time 
a.nd the tines at which it is required. Eor example, tomorrow’s in- 
voices may h vc to be printed today. In other words, data processing 
ha.s to be synchronised vd.th real time. 

4. Data processing and the real environment synchronises by 
using time as a data item. Eor exai^qile, orders of the month of 
Ilarch are identified by the date of order. 

As a system concept, conversion from a tine data item to real 
time identification and vice-versa, are needed. A case study given 
in Cha,ptcr 6 has an example where an amendment document has two 
time identifications. Aimendment entering on Monday, as the amend- 
ment for [Tuesday. In such cases at a tine, one of the time items 
appearsas a data item .and the other as a time tag. This is .achieved 
by tw/o features of tho language - 

1 . PERIOD nay be used to declare the time tag 

2. Data item nay be equated to a time-item. 

Tino as a system concept, also needs to allow additional tine 
intervcils, periods and sub-inteiwals which may be very specific 
to a system, Eor exarple four shifts a day is a specific interval. 
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Saturday to Friday week is a specific interval whereas Monday to 
Sunday week is a general interval. 

Time as a system concept, should allow making a reference to 
any point in time. For example, two days before today. For doing 
this, the current real time status should be ;'.vailable for reference. 
For example, one may like to check if the week of the order is current 
week- 


The user is cleanly a.ble to perceive timings of various operations 
in the system and the system designer is aHe to generate data items 
rela.ted to time. 


S 


main cyoLe 'I*'''”' , - part of the cycle for systen^ pro^ 

sub-cycle T -; Yj S ^ n-.* -p-art of the cycle cessing 

Prom the view point of computerised processing, a time interval 
nay be divided into three p^arts#* Beginning of the interval, when 
the system processing can be done* I^/ELddle of the interval during 
which things belonging to that interval, nay happen in the environment* 


End of the interval during which system processing can be campleted# 


For example, for the day, the order* s of the day have to be processed* 
It implies processing at the end of the day* llomrily end-of-the- 
interval processing nay be tn.ken as usual cond the beginning— of- th e-day 
processing na.y be considered only if there is a. special declaration* 

If the distribution of the processing is specifically complicated 


over different tiiae intervals and sub-interva.ls of tine then the 
block structure of description can be readily exploited* 
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4-5. DESCRIPTIONS POR INPUT DOCUMEMCS 

Essential features required for the description of docuaents 
or the inputs to the systen are similar to those for report descrip- 
tions. The noin difference is that reports ore nore structured than 
input docunents. The input fron the environnent is prepoxed by people, 
ojid hence the data is more raw, or less processed and therefore it 
is in simple forms. It noy have nore codes built into the data items 
to avoid data entry errors. Input forms noy have unfilled portions, 
wliich are allowed to be optional and in tho.t case they should not be 
used to gonorate data item strings. This occurs becauses forms have 
a rigid structure and do not adjust themselves like reports, depend- 
ing on the presence of data. This needs specicd. f eature in being able 

to ignore unfilled portions. 

Input media control procedures like skipping to a new form and 
input media condition sensing like creating a code from the line number 
on the form, etc., are similar to corresponding report description 
feo.tures. VAIUE clause for data items may be used to inscribe data 
integrity constraints on individual data items. In some cases the input 
medium may be linked to a message control system. Then input may have 
more report-like structure according to the presence or the absence 
of data. 

The case study given in the Chapter 6 illustrates these features. 
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SYITAX Og THE LANGUAGE 

The syntax of the language is given belovvu Report description 
part of tho language, vshich is given in Chapter III is being ooitted 
hero. Syntax for input descriptions is sane as that for report 
descii-ptions and is not being repeated. 

<APPLICATIOR-SYSTE[')I> : ;= <DESCHIPTION> MD>-OP-DESCRIPTIOH 
<DESGRIPTIOH> : <SI1TGLE-M0PU1E> 1 <IESCRIPTIOI > <SIRG1E-M0PIILE > 
<SIErGIE-MODUlE> : < THE -MODULE > |<OTHER-MODIILI^ 

<OTHER-MODTJIE> : :=< ITECESSARY-CONDITIOl > <Al'rY-MODDlE> 

<A1TY-M0DULE^ ; := <rji;POPT-MODTILE> ] < DOCroiEUT-MODTILE > 1 
<DATA-TEAESPOIffiIATI ON-MODULE > 

<REPORT-MODIILE > : := PPiPORT -^POET -DESCniPTIOlI > 
<D0CUMBNT-M0DU1E > : ;= <D0CUI![ENT-DESC3I[PTI0N > 

<NECESSARY-C0Nia:TI0N > : := < Et!iPTy > 1 < C CNDITI ON-DETAIL > 

< C0NDITI0N-DETAII> : := EACH <EELEVANT-DATA-ITEM> 

VHBN <SINGLE-ITEI'/i-C0NDITI01I > 

< EELE\rANT-DATA-ITEI'l> : := <DATA-ITEM >| <SYSTEf'I-DATA-ITEr'[> 

< SYSTE1),I-DATA-ITEM> : :=< TIME-CYCLE> ] <TIME-INSTAKT > 

BEGINNING 0E< TIIvIE-OYGLE> 

< SINGIE-ITE[\I-CONDITION> : := < DATA -ITEMx RELATION > < DATA-_ITEM> 

< DOCUMENT-DESCRIPTIOl^ : := DOCTEilENK DOCUIffiNT-NAl'IE >TO DATA SET 

< DATA-SET-NAB/1^<E0CUMENT-DETAIL > OVER 


COM'iffiNTs The document description is identical to report 
description given in Chapter III other than the 
following additions. 
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< RAHGE-OP-VAI.UE'> : s= <riANGE-OP-ViIiUES X EANGE-OE- VALUES < LITERAL > 

<a:iITERAL TO LITERAL > 

SIMPLE-PIDCEDUEE : := DIIPILLED, IGE0RE| < IHTEGRITY-OOITSTRAIRT > 

< VALUE-CLAUSE ^ ; := VALUE XeANGE-OE-VALUESJ 
<inTEGEITY-OOUSTEAISrT > s := ALL REQUIRED 


<COPY-STATEIIEUT > : := SAI'E-AS <M0DULE-KAI'!1E > 1 

SAME-AS <|.IODULE-MIffl > USING 
_(< SET-OP-PAKAIIETERS> 2 

<SET-OE-PARAMETERS> ; := <PARAI''[ETERS><SET-OP-P/J2AI,![ETEnS> ] 

<PAEAli[ETERS> 

<PARAMETE]> : := < SET-OE-WOiZDS> FOR <SET-0P-\70RDS> 
<SET-OE-V/OEDS> : := <\TORD> 1 <WOED> < SET-OP-UORDS > 

<LATA-TRANSPORI,IATION-MOLULE > : := LATA-DESCRIPTION 

< MODULE-MLIE > 

< DATA-EESCRIPTIOl > 

OVER 


< MODULE-M.IE> : :=< VARIABLE-FAlffl:f ffll. <EI',!1PTY> 

< DATA-DESCRIPTIOBr> ::= <DATA-LESCEIPTI01^< DATA-LE SCRIP II OR> | 

POR C MTA-COIIDITION > BEGIN 
<DATA-IE SORPTION > ETO | < DATA-Sa2ATEB.ENT > 

< DATA-C aiDITIOK> ; := <DATA-SELECTION>I <LiATA-SUISSErTING> 

< I)ATA-STATEF'/1ENI> : := <ENriTY-STATEBENT > [ 

<SET-PEOPEETY-GENEEATION > 
<DATA-ELEI!,'[ENT-GENERATION > 
<OTHER-STATEr.®NTS > 

< ENTITY-STATEMEHD> : :=< CEEATE-STATEf.IEM!> ] 

< ENTITY-SET-UPDATE > 1 

< ENTITY-PROPERTY-UPDATE > 

< CEE/iTE-STATEt.IENr > : := CREATE < SET-NAME> X‘SET-DOMINS>). 

< ENTITY-SET-UPDATE > : := ADD< SET-NAME>X<SET-DOBilAINS>J_ ] 

DELETB<SET-NAME> X^ET-DOIIAINS ^ 

< ENTITY-PROPERTY-UPDATE > : := UPDATE < SET-NAlvIB> X ‘^ET-DOIMINS ^ 
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< DATA-ELEIIENT-GENERATI01I> : := UIKB <VAEIA]3LE-FAiIE> = <A1J^-EA!E\> | 

lECEEASE <VArj:AISLE-ITAI/IE> <Aj3Y-DA'rA> | 
<I\roETIPLY-CEAUSE >4 OTHEn-Oi'iLCUIAIIOn > 

< AM-IiATA > : := <DATA-ITEM > j <LIEERAL> | <a}IIffi-IESTAErT > 

< SET-PROPEIlTY-&Effli:ilA!riOIT> : ;= Sm <I)ATA-ITm <VAiaABLE-HAIIE?> ] 

COUHT <DAPA-SET < VASIAHLE-Mi.CE> | 
iroHiEER OF <DATA-ITEMx SEQUENCE 
<VARIABLErNAME > 

< SET-DOBHAINS > : := <VAniABIE-NAME-STEING >= ^ OT < SET-NAIffi > 1 

/JJL OE <SET-N/JIE > | 

< VAniABIE-NAB/[B>= <DAPA-IPEM > | 

< YAEIAELE-NAIffi-STEINO j [ 

< SET-DOEAINS > , <SET-DOI.fIAINS > 

<SEQUEN0B > : := ASCENDING | DESCEBIDING 

<DATA-ITE[!1I> : :=< VAEI AELE-NAI.dE > | <VAia;7'J3LE-NAI'ffi> OP <DAIA-SET > | 

<DA!rA-I2EM > EEDESCRIBED BEGIN <DA1A-IIEM-STEING > EBID | 
POSIIION < INTEGER < INTEGER > 0^ <DATA-ITEM > 

<SET-NAliIE> :j= <DATA-SET-NA1.IE> < IOCAI-RENAME > ! < V/iRIABLE > : S_ jc YAEIilELE > 
<DATA-SET-NA1!.'IE >::=< DATA-SET >1 < DATA-SET > OP_ <TII/[E INSTANT > 

<71111 AELE-NAt/IE-STRING> : := <VAEIAHLE-NAlffi>l< VARIABLE-NAliEXVARIABLE-NAlIE- 

STEING> 

<D7iTA-ITEl!,I-STRING>: ;= < Vij;E:AELE-BIAB/IE-STEING>! <VARIABDE-NAIIE> PJCREATED 

< INTEGER > Tii'iEs 

< DATA-SELECTION > : := <VALDE-SELECTION >1< SET-STRING > 

<SET-CHECKING > 

<SET-GHECKING > : := < SET-Nii]VlE> <GHBGK > 

< CHECK > : := PRESENT I ABSENT I TYPE < SET-NAME > 

< VALUE-SELECTION ^::=< DATA-ITEKfc>?RELA.TIONX GITEN-ITEEI > 

< GIVEN-ITEM > : := <DATA-ITEIi!> \ <LITEEAL > | < TIIvlE-DATA-ITEI > 

< SET-STRING <SET-N/il£E> ^5I-NAMB> < SET-STRING > 

< SEQUENCING > : := SEQUENCE ON < SIMELB-DI-STRING > < SEQUENCE > 

< DATA.-SUBSETTING> : := <SUI3SETTING>i<SEQUENCING> 

< SUBSETTING >: := <TVro-SET-SELECTION > I <IlirEGER > TI1.ES 

BACH <SIlPLE-DI-STRING>i EAOH < TIME-PERIOD > 

< SELECTED-DI-STRING > [ - 

< TIME-TAG> 0P< DATA- SET > 

< DATA-SET> TYPE <DATA-SET > 
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< OTO-SET-SELEGTIOH > ; ;= < SET-IilCffi;>X *=SET-EOMIFS >2 

<SEDIDTED-DI-S!rRING > : := <DI-SELlDTI01ir> | < DI-SELEGTIOiT> <GOHirEGTOH > 

<SELEGTED-DI-STEING> 

<GC1MEGTOR> ::= , [AITO |OE 

<DI-SBLBDTIOJI> <SI]!/[PLE-DI-SBOuEGTIGff> |< ILVJGE-DI-SELEGTION > 
<SIMPEE-DI-SELEGTIO]\I >; := <EATA-ITEr'l>= <A1TY-ITEM > 

< MNGE-DI-SEEEGTIOH > ; := < DATA-IEEM > = <VAIiUE-STEIEG > 

< VALUE-STRING > : := <ANY-ITEM>| <VALUE-STRING>j_ <VALUE-STRING > 

<AirT-ITEM :TO<ANY ITEM > 

<GLOBAL-EEFAIjIE> ::= <DATA-SET-MME > DEPIHEI) AS <DATA-SET-NAI'.IB > 

< OTHER-STATEMENTS > : := <GOPY-STATEJIEHT>| <GLOBAL-REN;iME' > | ~ 

<LOGAL-RENAME > | < VERSION-TIIIE > 

<EOG/ii-RENAI/lE > ; := < DATA-SET-NAME > GALLED < DATA-SET-NAME > 

< VERSION-TEIE > : := PERIOD <E CEM/iTTED-TII/EE-INSTAJ^ID > I^ < GIVEN-ITEM > 

OT <SET-NAME > 

< TIME-PORMAT > : ;= < SUB-OYOLE> ^ <SUPER-GYOLE >BY<jroM3ER > | 

< GYGLE> m^mBER >|< GYCSLE > ^ ^AlflE > | ' 

< TIME-EOIMAT > , < TIME-EOEMAT > 

< EOmi/iTTED-TIME;-INSTANT> : := < TIIffi-INSTAHT >X<TIME-POEMAT ^ 

< GYGLE >::= BM \ WEEK | YEAR | MONTH | QUARTER [ HOUR < USER-GIVEN-G YGLE > 
<USEEr-GIVEN-CYOLE >: :=< SUPER-0 YGLE >| < SUB-OYCLE > 

< SUPER-GYGLE > : := < SUPEE-CYOLE-DEEINITION > 

< SUB-0 YGLE > :s= PERIOD < INTEGER > < VARIABLE-NAME > OT < VARIABLE-NiUCE > 

< TIME-DATA-ITM > : := < TIME-INSTANT ^ <5'0RMATTED-TIME-INSTANT > 

<TIME-INSTAHT . > : TODAY | TOMORROW | YESTERDAY | 

< USER-0 ONSTRUOTED-INSTANTS >] 

< SYSTH/t-OONSTRUOTED-INSTANTS > | 

< USER-DEEINED-INSTANT > 

< USER-G ONSTRUOTED-INSTANTS^ : s= < GYGLE-GOUNT > < OYOLE > 

< TIME-RELATION >^IJIE-INSTANT > 

USER-DEEINED-INSTANT > : := PERIOD < VAEIAiBLE-NAME >EROM <TIME-INSTANT 

< OYOLE-OOUNT > : :=< EMPTY >]< INTEGER > <riME-INSTAHT > 


> . 


< TDIE-EELATION 


•REEORE I AETER 
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< SYSTM-CDNSTEUCTED-IITSTAKTS > : := CTJETuECTT < CYCLE > | 

LIST < CYCLE > I 
liTEKT <CYCLE> 

< SUPER-CYCLE-DEEim:TIOEr > : ;= < OVER-LAPPED-CYCLE “ I3EPIITILIOn> | 

<EVEN'-CY:!LE-DEPIEI!riOE > 1 
< III EVEN-CYCLE DEEINITION > 

< OVIELAPPED-CYCLE-DEEINITION > : := PERIOD < USER-CYCLE > 

IS EROM <TII,IE-INSTAira> TO <TII®-IlISTAN!r> 

< EVEN-CYCLE-DEEIin;TIOE> : ;= < EVEN-CYCLE > 

< BVEN-CYCLE> : := PERI OIK USER-CYCLE > ^ I'1/J)E OE < INTEG-ER x CYCLE > 

< IMEVEN-CYCLE-DEEINITION >::= <UNEVEN-CYCLE >1 < UNGVEN-CYCLI> 

<UNEVEN-CYGLE-I)EPIIETION > 

< UNEVEN-CYCLE > : := PjIIIOD < USER-SYCLE> _(.<CNTEGER ^ 

i§ I'/IADE OF <INTEGEE > < CYCLE > 

< USER-CYCLE > : := <VAHIAHLE-N;iI.ffi > 

< EVEN-CYCLE-NAIIE> : := < NAIiE-CLAUSE >]cNA]!/E-CLAUSE xEVEN-CYCLE-NAIiE > 

< NAliIE-CLAUSE> : := NAIE OT< CYCLE >X<I^TTEGER ^ <LITSnAL > 

A-7. CONCLUSION 

The systieti description approach taten in the language described 
in this chapter preserves nost of the structure of user’s system in 
a usable or understandable form. This is achieved firstly by using 
tine as a. system concept. By eliminouting explicit use of loop- 
structure by providing features for data cardinality and different 
kinds of update requirements. 

To give completeness to the foimal system description, inputs 
can aiso be described using the DOCUICBNT feature. Timing needs of the 
system and its relation with the environment, can be ixitegrated with 
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the system description, A limitation of this approach is that it 
does not aim at getting the informational ■view of the system or 
■understanding the system hut it only aims as getting a precise data 
model of the system and depends on the user to he ahLe to state his 
information req^uirenents in terns of data requirements. In this way, 
insteo-d of making the description fully declarative, it remains 
proced^ural to the extent that the ^knovi/ how’ of data associations for 
the required inf orcntion has to he given hy the user. 

At the detail level, "the different kinds of data mappings may he 
obtained hy the nech<aiaisns of subsetting, data selection and data 
generation. Built-in mechanisa for 1 ^ M subsetting, 1 M data 
selection and M 1 (cODNTjSIJM), 1 -^1 (REPOIH data items), 1 M 
(IUI/EBER) data generation have been provided. Here 1 M etc use M ' 
in a general sense of either a set or an elenent . Hov/ever , M IT 
napping on all the three nechanisQ, in a user described^ explicit 
nanner is facilitated by using the block structure and the related 
subset naming neohanisn \Aiich is implied by the structure# A limita- 
tion at this level, is that the subsetting procedures can put one 
elenent of the set, only in one of the subsets o-t a tiae# If multiple 
copies of an elenent have to be put in different subsets then this 
can be indirectly done by selecting more copies at the beginning of 
a procedure* However, this limitation also limits the user from 
making unreasonable descriptions while being xmaware of it* 
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In the endj it can be said that the approadk leads to a sinple 
description, concisely, so that the description con. be used for 
conputer-aided analysis and design. It is structured to naintain 
the structural properties of the described systen at a usable level. 
An inf ormo.tion systen links itself vd.th reality and the associated 
organisations or the firn by inputs, outputs and the associated 
tinings. Ihese facilities are provided in this approach for conplete 


ness of description. 
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SYSTMS AlI/iLYSIS 

In the last two chapters of the thesis a system description 
langungej SDI, has been deyeloped which can be used to fully des- 
cribe 4>n information processing system required by the user. The 
inputs, outputs and the timing desci-iptions fomulate the inter- 
action of the information processing system with its environment 
or the organisation vdiich will use the system. The data transfor- 
mation descriptions fomulate how the system should hehave, or 
shoTold work out the data associations. 

Such a description can be used as a doctiraentation aid to the 
systems analyst. It will, however, be of much greater impact if 
it can be used a.s a design aid. In this chapter we will discuss 
how such a description can be used for computer aided system analysis 
and design. Systems analysis, today, is done manually by a systems 
aaralyst. In the following section, we i/ill discuss how simple ana- 
lysis about the availability of the required data, can be done. Then 
we will proceed to discuss why such an analysis is much less than 
what a systems analyst does. In Sections 5-1 to 5-5 we will discuss 
some new methods of systems analysis which exploit the structure 
of SDL, for interactively extracting inforna.tion relevant to analysis 
and design. 
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let us start with a snail exo-inple of a system which keeps master 
information about the costs of products* This system receives invoices 
and checks certain items like discount a.nd product value. It is an 
invoice audit* It prints out a report for those invoices where some 
discrepancies are found* The description of reports^ inputs and data 
transformations are given in SDL in the follow/ing* (The format; dia- 
grams of input foims and reports are given purely to assist the reader.) 


PRODUCT POEI/[ 


(l0 Lines per form) 


PEODUCT 

CODB 

STANDAED 

LABOUE 

PEICE 

STAHDAED 

ItoTEEIAL 

PEICE 

mimm 

EISCOIMir 

PEECEM! 

DESCEIP- 

TIOE 

SEELIEC 

PEICE 

1345 

97.34 

13.56 

1 2 

TIPB-1 

153.67 



72 


FOH E/iCH DAY 

boCUI/IMT PEODUCT-DOEM TO DATA SET POST-MAS TER :S 
^OR each 10 COST-mSTERsS BEGIE 
EEW-EOEIiJ AETER 5 DINES 
EOR EACH GOST-MASTER BEGIN 

PRODUCT-CODE, STANDARD-LABODR-PRICE, STAHDAED-MATERIAD-PRICE 
SELLING-PRICE DESCRIPTION MAX-DISC CON T-PERC El® END 
ECEMAT PROLUCT-CGDE PROM 4 SIZE 4 STA NDAED-LABOUE-PEICE 
PROl 11 PICTURE 99,99 STAEDAED-MATERIAL-PRICE PROM 19 PICTURE 
99.99 MAXIMDM-DISCOUNT-PERCENT PROM 28 NUlffiER SIZE 2 DESCRIPTION 
PROM 32 SIZE 10 SELLING-PRICE PROM 45 PICTURE 999.99 
OYER 


INYOICE POEM 

PRODUCT CODE 1345 INVOICE-NUMBER 1001 YE/iR XX YffiEK-NO XX , 

f ! 

I CLASS OP TRADE XXX CUSTOMER NOS 1056 AREA LC QUANTITY 50 

I 

PRODUCT VALUE XEIOC 

DISCOUNT VALUE XXXX SIGNATURE STAMP I 


POE EACH DAY 

DOCUICLNT IN70ICE-P0EM TO DATA SET INVOICE :S 
POR EACH INVOICE BEGIN 

NEYf-PORM APTEE 1 LINE, PRODUCT-CODE, INVOICE-NUMBER, WEEK-NO 
YEAR-NO NEW-LINE CLASS-OP-TRADE CUST0M2R-N0, AREA 
QUANTITY NEW LINE PRODUCT VALUE 
NEW-LINE DISCOUNT-VALUE END 

PORMAT PRODUCT-ODDE PROM 15 NUMBER 4 INVOICE-NUMBER PROM 34 
NUMBER 4 YEAR-NO PROM 44 SIZE 2 WEEK-NO PROM 52 SIZE 2 
PRODUCT-VAIUE EACH 15 SIZE 4 DISCOUNT VALUE PROM 15 SIZE 4 
CLASS OP TRADE PROM 15 SIZE 4 AREA PROM 44 SIZE 2 
QUANTITY PROM 5 2 NUMBER 2 CUSTOMER-NO PROM 34 SIZE 4 
OVER 
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EEPOnr OU IIWOIGE EHETIHG PAGE 1 


PRODUCT 

INVOICE 

OALCUL/AED 

PRODUCT 

WiZIMDM 

DISC (UN T 

CaLCENT 

CODE 

NO 

VALUE 

VALUE 

DISCOUNT 

VALUE 


0513 

10 

53.5 

53.0 



COIi'IENT-1 

0600 

1 



10 

12 

COMi'IEHT-2 

0713 

5 

60.0 

65.0 

9 

15 

0 0 
0 0 

JZD 

0613 

6 

23.5 

23.0 



C aCIENT-l 

♦ ♦ • f 

1 

0 # 

• • » • 

.... 

P 





m • 

• » • * 

• • • • 














POE EACH DAY BEPOEP IIWOICE-EDIT 
EEOM DATA SET IEVOICE-AUDITjS 

DLAITK 1 2, "REPOET OE IMVOICE EDITIIIG, ” PAGE-FDlffiER 
FEV/-LIIE, HEADIEG-LIIIE -1 5 EEV-LIEE, HEADIlirG-LIlIE-2 
EOS EACH OE TtlE INVOICE-AUDIT BEGIN 

EOR DISGODNT-ABOVE-MAZ = 1 OR V.ALUE-DISCrLEPANCY-COUlTT = 1 BEGIN 
NEY/-LINE, PRODUCT-CODE, INVOICE-NO 
EOR VALUE-DISCEEPANCY-OOUNT = 1 BEGIN 
CALCUIiATED-VALUE, PRODUCT-VALUE ^ 

EOR DISCOUNT-ABOVE-MZ = 1 BEGIN 

IL’GailM-DISCOUNT, DISCOUNT-V/JLUE END 
C Q'/MENT-I 

EOR COMIMT-1 = EL/JIK BEGIN COM.IENT-2, ^ 

EOR COM,IENT-1 ^ BLMJK COIIIENT-2 7 ^ BL.ANK BEGIN 
NE¥ LINE, COMi;£ElTO-2 ^ 

EOR NETf-PAGE BEGIN PAGE-NUlffiER BED 
EORIfcT HEADING-LINE-1 EROM 1 VALUE 'PRODU"- 
-'»CT INVOICE CALCUL/iTED PRODUCT MZISfflM DISCOUNT COMMENT" 
irEADING-2 EEOM 2 VALUE "CODE NO."- 

VALUE VALUE DISCOUNT VALUE" 

PRODUCT-CODE EROM 2 SIZE 4 INVOICE-NO EROM 12 SIZE 2 

C/JiCULATED- VALUE EROM 24 PICTURE 99.9 PRODUCT-VALUE EROM 36 PICTURE 99.9 

MZIMUM-DISCOUNT EROM 45 SIZE 2 DISCOUNT-VALUE EROM 55 SIZE 2 

COM/ffiNT EROM 60 SIZE 10 

OVER 
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FOR Ei.CH DAY 
DATA-DESOEIPTIOg EDITIIG 
POE mrOIGBtS GOSE-MSTEE:S BEGIN 
EOE EAGH INVOIGE BEGIN 

POE YEAE-NO = GDEEENT YEAR BEGIN 

POE GOST-I/ASTER (PRODUG T-G ODE = PEODUGT-GODE OP INVOIGE ) BECaN 
GAICIILaTED-VALDE = SELLING-PRIOE * QUANTITY 
POE GALGULATED-VALUE 7^ PEODUOT-VALUE BEGIN 
MANE VALUE-DISGEEP/iNCY = '1 " 

MAKE OCftiIENT-1 = ''VAinE-DISGEEPANGY" EIID 
MX-DISGOUIfT- VALUE = GALGULATED-VALUE * MiUC-DISOOUNT-PERGENT 
POE MX-DI SO OUNT- VALUE <DISGOUNT-VALUE BEGIN 
I.IAKE DISGOUNT-ABOVE-]yiAX = "1 ” 

MAKE OOIttENT-2 = 'DISCOUNT ABOVE B-IAX" END 
CREATE IITVOICE-AUDIT (COI®ffiHT-1 ,COIi£ENT- 2, CALCULATED-VALUE, 
PRODUCT-VALUE L^XHiCOM-DISC OUNT, DISCOUNT- VALUE 
PRODUCT-CODE INVOICE-NUMBER QUANTITY DISGOUNT-ABOVE-IIAX 
VALUE-DISCEEPANC Y-COUl^T ) 

OVER 


Two inputs, nrmiely PRODUCT POETl and INVOICE POEM, one report 
INVOICE AUDIT and EDITING data transformation, are used to describe 
the system. To analyse the system da.ta needs for the reports and data 
availability from che input documents will be derived. Also, some 
data I ay not be available directly from the documents but from data 
transformations. Data transf oxnation may need some data to carry out 
the transformation, and that shoilLd also be available in the system. 

In the following description the data will be represented as relations, 
for each of reference. Every data item will be given a composite 
name as 'data-item of sot-name'. Every relc-tion (as used here) vd.ll 
ha.vo 4 constituents : a relation name, an associated set name, a set 
of key data items, a set of attribute data-items. 
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A procedure to derive the da.ta needs fron reports has already 
been given in Chapter III. Similar procedure can be written for 
getting da.ta availability from the documents. A similar procedure 
is given below to get the data needs and do,ta availability for the 
data transformations, 

1 . Identify the data items with only one of the data sets 
used in the data transformation module, if there are more than one data 
sets . If two or more data sets have same data item name then iiie user 
should be asked to clear the error. In the above example, in the 
EDITING nodule, QUANTITY will be associated with INVOICE and SELLING 
PEECE with GOST-MASTER. If there was a SELLING-PRICE in the invoice 
also then either the description should be CALCULATED-VALUE = QUANTITY 
* SELLING-PRICE OP COST-IiIASTER or the user will have to clear the doubt, 
Por left hand side items of Ii/[AKE and the calculations, a set name shoiiLd 
bo generated and associated. 

2. Associate a level-number with every data item, by starting 
with level -No. 1 and increasing the level— No. by 1 with every BEGIN c.nd 
decreasing the level-No, by 1 with every END . The do.ta-itens should 

be entered in the sequence in v\hich they are encountered, to maintain 
the block structure of the description. 

3. Por each statement of the type POR EACH data set , introduce 
a special data item as IDENTIPICATION-NO at the proper place in the 
table, with the proper level No* 
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4. Mark all the data, iteas on the left hand side of a colcula.- 
tion, MAKE and CEEAIE as ojvailahle type « All those on the right 
hand side are to be narked as 'K' or needed itens. 

5 . Mark all the items in EOH statenents, excluding those on the 
right hand sides, a.s KEYS or ’K’. Others are to be narked as ATTRIBUTES 
or ’A’s. Use ECR statenents TOLth equa.ls using two da.ta itens, to list 
the synonyms. 

6. Repeat the following steps for all the attribute type of itens, 
to gonera^te relations. Also repeat for the lowest key of relations 

of the typo 'A’ or available. 

7. Take the level Ho. of the data-iten. Reduce the level by one. 
Put all the key itens of the first occurrence of this level as the keys 
in the relation being generated. 

8. Repeat Step 7 till the level-No. bee ones zero. 

9. If the attribute is not a generated iten, then keys belonging 
to its own set none are to be retained only, 

10. All the relations ■vhich ore identical but for the attribute 
data none nay be consolidated in one relation by putting the attributes 
together as a set of attributes. 

A list of relations, as worked out by applying the above procedure 
is given below. Codes are introduced for readability, within the 


parantheses . 
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Feed or 
quolibi] 

Relation 

Set-name 

Keys Attributes 

(from 

report lilVOIGE-EDIT) 



F 

R1 

IWOICE-AiULIT 

(si ) 

IDEITIEI GATIOF-FO 

(si id) 

DI SG ODFT-ABO VE-MAZ 

(si El ) 

VAIUE-DI SGREPAITG Y- 
GOJHT 

(S1E2) 

PRODUGT-GODE 

(S1E3) 

INVOIGE-FO 

(S1E4) 

F 

R2 

SI 

SI ID, SI El, S1P2 

OALGDIATED-VALUE 

(S1E5) 

PRODUGT-VALUE 

(S1E6) 

F 

R3 

SI 

SI ID, SI El, SI E2 

MAZBiIUIil-DI SG OUFT 
(S1E7) 

DI SO DUFT- VALUE 
(SIES) 

F 

R4 

S1 

SI ID, SI El, SI P2 

COIEIEFTI 

(S1E9) 

N 

R5 

SI 

SI ID, SI El, SI E2, 
S1E9 

COM,IEFT-2 

(SIEIO) 

F 

R6 

SI 

SI ID, SI El, SI E2, 
S1E9,S1E10 

S1E10 

(frcri docimoiit PIIODUGT EORl'l) 



A 

E7 

GOST-MASTER 

(S2) 

IDEFTIEICATIOF 

(S2ID) 

PRODUGT-GODE 
(S2P1 ) 


STAIIDARI>-I>/iBODE- 

PEIGE 

(S2F2) 

VALUE 

(S2P5) 

SEELIUQ-PEEGE 

(S2E4} 

LESGRIPTIOIT 

(S2E5) 

&IAX-DISGOD1IP- 

PERGEHP 

(S2E6) 
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ITeed or Relation Set Naue 

avail ability 

(iron docuaent ILTVOICE ROM) 


Keys Attributes 


A 


RS INVOICES 

(S3) 


IDEIWIEI CATION (S3E1 )PRODUCT- 
(S3ID) GORE 

(SSRa) IMOICE- 
NUlffiEE 
(S31'3) lEiH-HO 
(S31'4) GUSTOICEE- 
NO 

(S31'6) AREA 
(S3E7) QUANTITY 
(S3P8) PRODUCT- 
VALUE 

(S3P9) DISCOUNT- 
VALUE 

(S3S10) li/EEK-NO 


(frora data transf onaation EDITING) 


N 

E9 

S3 

S3 ID 

S3P2,S3E7,S3E1 

11 

RIO 

S2 

S2E1 

S2E4 

A 

R11 

NIL 

(S4) 

S3E3,S2E1 

S3ID 

calculx;ted-value 
(S4P1 ) 

N 

HI 2 

S4 

S3E3,S2P1, 
S3 ID 

S4E1 

A 

R13 

NIL 

(S5) 

S2E1,S3ID 

VALUE-DISGEE- 

PANGY 

(S5E1 ) 

OOMffiNT-l 

(S5E2) 

A 

R14 

NIL 

(S6) 

S3E3,S2P1, 

3311 

monism, i-Di sc ount- 

VALUE 
(S6P1 ) 

N 

R15 

S4 

S3E3,S2E1 , 
S3 ID 

S4E1 

N 

El 6 

S2 

S2E1 

lAAX-DISGOUNT- 

PEECENT 


(S2E6) 
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Ifeed or 

avail ability 

Relation 

Set Noxie 

Keys 


Attributes 

H 

R17 

S3 

S3;d, S3R3 


S3P9 


R18 

S6 

S2R1 , S3ID, 
S3P3 


S6P1 

A 

R19 

S7 

S2P1 ,S3ID, 
S3P3 


RISCOUITT-ABOVE- 

IIAZ 

(S7P1 ) 

COilIEHT-2 

(S7P2) 

A 

R20 

S1 



QUAITTITY 
(SIFII ) 

S1P1 ,S1j[?2,S1P3, 
S1P4,S1P5,S1P6, 
S1P7,S1P8,S1P9, 
S1P10 

N 

R21 

S3 

S3P3,S3ID 


S3P8 

I/Iatching of 

the relations - 

can be shown 

as follows : 



HI, R2, 

R3, R4, E5, R6 

R 20 

R 18 

RU 


R17,R9 ■ 

^ R8 


HI 2 ■<- 

R8,R11 


R16,R10 

■^R7 


R15 ^ 

R11 



Superfluous data: S1P11, S2F5 

Olie above kind of nofching is simple data analysis. There nay be 


loops of data transformation in the definition. Tor this, further 
analysis may be done to identify errors in the definition. The above 
kind of analysis is present in the softv^cjre systems #iich do computer- 
aided analysis. However, a systems analyst normally would hc^ve done 
the following analysis to find some more shortcomings of the a.bove 


description 
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1 . Hiis systen description can have two interpretations. Product 
forns for all the products nay he required every day or product foms for 
only the new products nay be accepted everyday G.nd nay be used alongvri.th 
the old product infornation. If needis to be nade clear, as to which of 
these interpreto.tions is correct. User nay assune that it is a well 
loiown ccnventionol fact. 

2. If a naster record is absent then also the invoice should be 
narked for audit. 

3 . If the year is not correct then the invoice should be narked 
for audit. 

4. If invoices are read product— wise, it nay involve less reading 
of infornation. 

5. If there ra-e two products in the sane product code then sone- 
thing should be done, unless it is o.n integrity constraint for the 
system 

Iliis brings out sone of the other aspects of real life systen 
analysis. The structure and the level of the language developed in 
tills thesis, has been selected in such a way as to facilitate nore 
detailed systens analysis. In the following sections, we will discuss 
how the systen descriptions nay be refined, by interacting with the 
user in relation to various aspects of design and analysis, like 
integrity, selection, subsetting and cardinality. 
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5-1 . DATA IITTEGRIIY AMD SUBSETTICTG 

At any level of processing only aggregate properties of the 
subsets nay be used, for data selection and genero,tion. If the sub- 
set itself is an clenentj then all the elenent properties nay be used 
for such a purpose. 

To explain this by continhing the sane example let the invoice 
audit system be expanded to Tseep product master information for 
'^.ifferont branches of the sane product, using only one product code 
for one product. In this example the situation is very clear and the 
user nay account for it. But in nany cases omissions are nade. In this 
situpfion the user should either put it as an integrity constraint or a 
necessary reiuirenent frcn the da,ta that there vdll be one cost-naster 
for one product-code or user should do further data selection to identify 
the product with proper selling price and then use the information. 

The following procedure nay be used to identify such situations and 
generating a query for the user. 

1 . Do the following for each data description nodule for sub- 
sotting for en.ch data set used, taking the sets one by one. 

2. Dor the set, cron.te a list of level -wise items, for those items 
vhich are used in the subsetting operations. If data item is used 

in data selection or generation at a certain level, but it is not 
available in the table at a lower level then the following query should 
be generated: "WILL THERE BE OHLY pKE COST-MASTER (or the data set used) 
DOR A MIQUE PRODUCT-CODE (or set of ITEti 1, ITEM 2, ... for all the 
entries in the table for lower levels)?" However, if the subsetting 
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is due to un elcniont level before such use, by a 'FOR 3A0H data-set' clause. 
Then, no ness age is generated. 

3. If the answer to the query, generated in the previous step 

is 'yes' then it becones an integrity constraint to be checked during 
creation or update of GOST-MSTEEs. 

4. If the ansvrer is 'no' then a new query "IF THERE ARE IIORE TH/iH 
ONE COST-BttASTERS (or data set used) HOYI TO SELECT SEL1ING--PRIGE (or the 
dcata-iten which generated tliis query)?" is generated. 

One more problem in the example could be identified, A COST— IIASTER 
may not be present for a PEODUCT-COEE or an invoice may have a vn?ong 
PEODTJGT-COnB . In data pro ces, sing such checks have to be made. User 
nay not bo aware of this though his organisation nay be na.king a nanual 
chock for such a, problem. This can be analysed in the following way. 

1 . Bo the f dlowing for every data transformation nodule and for 
every data set. Identify rll the data subsetting classes which use da.ta 
selection such as GOST-MASTER (PRODGT-COBE = PEOBtJGT-GOBE OF IWOIGE), 

For these transformations do the follomng - steps. 

2. Sco.n further description to find out if the user has checked 
the presence and absence of the selected data set. If it is not so 
then do the following step. 

5. Insert a query just after the statenerrt. "IF THE GOST-lE's.STER 
(data set) FOE PRODUGT-GCDE = PROBUGT-COBE OF INVOICE (the expression) 

IS ABSENT? CAN IT BE ABSENT? 
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. 4. If the answer is 'Ho’ then ask the user to insert an integrity 

chock sonev^here, if possible. 

5 • If the ansvror is 'Yes' to query in Step 3 the user v/ill introduce 
the required data transf ornation(s ), if any. 

5-2. DATA CARDIHALIfY 

The structure of the langur'ge is sudi that it nakes the user av/cne 

of the sots cund elcnents at any stage. The user is discouraged fron 

thinking in torus of embedded and repeating groups. If the cardinality 

of these sots is knov«i at different levels then this could generate 

good design inf oracLtion. For ex anp l e ; 

* FOR E/'.OII CUSTOi/IEE-IO OP IHYOICEsS BEG-IH 

COIJITT IHVOICE;S ^ IFVOIGES-OF-A-GUSTOI'ffilR 
FOR EACH INVOICE BEGIH 

1 tFQE COST-MSTEE (PRODUCT-C ODE = PRODUCT-CODE OF liWOICE) 

BECIH 

mm /ilOIMT-l = STAl®AED-LABOUn-PRICE 


etc 

Let there be 10000 invoices, 200 customers and 20 products, approxim-'.tely 

500 invoices per customer and 10 products ordered per oust oner. Rea.ding 

of COST-IiASTER can bo reduced from 10000 to 2000 if da,ta selection is 

done product-wiso. Such areas could bo located by the following method. 

1 . Select data description modules with two or more data sets. 

2- Ask the user to give average volume of da.ta in those data sets 

"APPE0XIIIi:/.TEDY HOU lI/iHY IHVOICES AT THIS POUT" 

(data set) 

3. If there is an order cf difference between the two volumes 


then analyse as follows 
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^4. Scan end locate the first da,ta selection for a second data 
set. ‘'''Scan backwards froa that point, by ignoring the 
procedures for calculations and any 'POR EilGH data, set ’ 
clause. Scan back only till sorae other operation is found 

5 . If no ’EACH data set' clause was ignored in this process 
then abandon the analysis for the current data selection. 
Otherwise query the cardinality at the point of current 
scan as follows: 

"HO’y IIAHY HEEPEREHT VALUES HAS PRODUCI-COLE (the data iten 
of data selection being analysed) EOR SET OF IFVOIGES 
(data set name at current scan point) AT THIS LEVEL?" 

6. 'AT THIS LEVEL' part can be refined specifically giving. 

all the sfelection data items of the subset Class at this stage 
like 

"IFT0ICE3 FOR A GIVEKT GUSTa'/ER-HO''’ " 

7. If the answer is more than one then data selection under 
analysis can be lifted to just below the point of back scan. 

5-3. AHALYSIS OF UPDATE 

The system description often has omissions about strict update 
sequences, deletion facility, and the cycle of update. Updates rare 
generally used on data which is about entities with long life time, 
data, which does not become obsolete after a tine cycle and data 
about viiich deletion, up date etc, are needed as a result of the en- 
vironmental conditions. Sequence of different types of updates also 
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slioiold bo specific. Por exauple every uontli the selling pxice uny 
be updated for a product, if there is data for such update. Suppose, 
due to sole policy of investment, returns and coapetition, it has been 
decided to slo.sh the prices by one percent every six nonths. In this 
case, the precedence of six monthly and monthly updates mil ha.ve to 
be specified. One may of specifying it by declazing it as a data 
transformation a.t the beginning of the six monthly cycle. Such a 
dobl miration will implicitly make use of the convention th^t the begin- 
ning of a, smaller cycle is later than that cf the bigger cycle. Por 
exai-iple, monthly processing a.t the beginning of a month will conven- 
tionally be done before the daily processing, on the day of the begin- 
ning of the month. 

Product-Porm 


7 

\ / — 
Dolu'timn--f orm 




Cost-Master 




DelUjtions 

''’n 


->-1. 


P2 


P5 i 




/ ; Other-Sets 

V J 

" 


Product Porm 


/ 

z: V- 


P1 


Pcletion-Jorm 


\ , 
\/l 


Cost Master 


\ 




Cost Mastd 




■131 



J5 


Deletions 


Cost Ife-ster 

V>-4^ 



( ' Other- -Sets 




-!P5 


Pigure 5-1 : Updating Data Transformation. 
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Another problen in describing updates is illustro-ted in Ihgure 
5-1 . Ihis problera has also been pointed at the aid of the Section 


5-1 . Tlie problaa is that of identifying vdietll^*all the COST-MSTEES 
are newly created every day or only those for new products are crea- 
ted and added to tho ones already present. This problen can be a.lgo- 
rithih-cally identified fron the descriptions in the following my. 

1 . Do the folloThng for all data sets. Check if an 
UPDATE, /iDD or DELETE stataaent is used. If these 
are used, then nark this data set as o-n entity 
oriented data set. 

2. Out of the renaining data sets select those which 
are being generated directly fron an input f om. 

If the data itens fron any of these sets are being 
used over a, nunber of tine cycles then this is likely 


to be an entity oriented set. 

3. Eor all the data sets narked so far as entity 
oriented sets do the following steps. 

4. Check the cardinality handled by the creating process 


by creating the quezy; 

"APPROXIMATELY HOW MAHYCOST-MSTEES (data set name) 

ARE CEE/iTED 

EVERY TIME?" 

5 . Chock the cardinality handled by the using processes 
by creating the query; 

"APPROXIMATELY HOW MAHY COST-MASTERS (data set nane) 

ABE THERE?" 
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6. If the answer in Step 5 is greater than twice the 
answer in Step 4 then this data set is likely to 
be a growing set updated at tines. 

7. Take all the creating processes for the data set 
one by one and generate the following query 

"IS THIS GOST-WiSTER DATA TO EE ADDED, TO THE OTHER 
COST-MASTER (Mta set nand)DATA THAT IS ALEE/J)Y THERE? " 

8. If the answer to query in Step 7 is yes then change 
the CREATE to ADD and display to the user. If the 
user finds it unsuitable then he nay give the correct 
version. If he accepts it then one nore display nay 
be uade as in Stop 9. 

9. "THE VERY EIRST THIE THIS TttLL BE CREATIHG A mil 
COST-MASTER ALSO." 

5-4. OOHCIUSIOH 

In conclusion it can be said tha.t the structure of the SDL can 
be exploited to algorithnically analyse the systen description. Such 
a.naJLysis has two ains. On the one hand it tries to get a logically 
Gorruct and conpletc description and on the other hand it can gathor 
infomation for design and introduce changes to nake it suita,ble for 
data processing. 

Sono methods of such analysis have been developed in this chapter, 
Moro such analysis can bo systematically done if important da.ta processing 
aspects of any description can be conceptualised. ^ 
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Pron the design point of view, it can be said that better opti- 
mization can be performed at a level at vfaicli the structrure or the 
problem or the intent of the user is more clear. Designing of da.ta 
partitions and processing programs is a difficult problem of optimization 
because for a data set, the organization and the accessing method of a 
cmputation using it, can not be determined independently of each other 
or of other data set organisations and computation accessing methods. 

Ihe organisation of a data set limits the ways in vdiich it can be 
practically accessed by a computation and the accessing method of a 
caaputation restricts the practicable organisation of a data set that 
it accesses. But business systems are highly sequential and the problem 
structure can be interactively used to collect the design information 


fraa the user. 



CTiAPTER 6 


A CASE STUDY 

System description language should provide ease of use and a 
repertoire of concepts to describe all the relevant aspects of a 
number of users ^ systems* In this chapter a case study is deve- 
loped using the system description language presented in this thesis* 

A case study is taken fron f CLI 1 ]. Due to some discrepancies found 
in the problem analysis^ the problem has been modified. The selec- 
bed case study becomes difficiiLt in terms of data descriptions ^ at 
certain points and illustrates that without the use of a host lan- 
guage, the system can be completely described in SDL* 

C-1 • PEOBLEP,^ DESCRIPTION 

A complete word statement of the case study is not being given 
here as it will take a lot of space and also it is a need of the formal 
description to be readable. Certain points which are important in the 
case study are being described here. 

In the case study given here an information system is needed for 
a bakery to expedite implementation of changes in the customer require- 
ments and orders. Every day a list of all the commodities viiich are 
to be baked, is created. Bakery is used during the day to prepare 
confectionary items and during the night bread. Therefore, confec- 
tionary items to be sold the next day are loaded in the bakery in the 


morning* 
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Jivery day a list of the commodities in short supply is prepared. 
Orders related to these commodities are eliminated before the bakery 
load is prepared. After the items are ready in the bakery they are 
sent to six loading bays in sufficient quantity for each bay. There 
are delivery vans -vhich have an associated round number (identifying 
the route allocated to a van) and a loading bay from vdiich it gets 
loaded. Each customer is associated with a fixed round number accord- 
ing to the address and location. 

Vans make one or two deliveries on the same route according to 
the ordering requirements of the day. These vans have delivery-men 
incharge of the van who are given a delivery note for the day to 
deliver the orders to the customers. The orders vhich are not fixL- 
filled due to non-availablity ctf the commodity are notified to the 
customer. In case certain items are not taken by a customer, inspite 
of the order or are taken extra by a customer, if available, then the 
delivery-men make a note of it and fill the returns and adjustment 
forms to be submitted to the bakery, immediately. 

The more complicated aspect is that of order collection which 
is also done by delivery— men. Orders are accepted on preprinted 
forms, OIvJR documents #iere the delivery man makes only a mark on 
the code provided. It has been done to simplify things for delivery' men 



91 


About 50 lines are acconodated on each fom. There are about 1 20 
confectionary items which take three preprinted forms and one pre- 
printed form for bread items is sijfficient. 

Every week, preprinted forms are created by the computer by 
additionally printing the day and the week on the preprinted form. 

Eor each day, the forms are printed. These are used over the week. 
Each fcarm can be used to create the orders for all 6 days of the week. 
The commodity is identified by the line number on the form. If the 
order is temporary it is a temporary change to the standing orders, 
otherwise a permanent change. The system maintains standing orders 
for customers for all six days of the week for all the required 
commodities. Confectionary items have to be ordered two days before 
vAieroas bread items have to be ordered just one day in advance. 

6-2. IHEOEI'IATIOH SYSTEIJ DESGBIPTION 

The relevant inputs, reports and data associations are described 
in the following pages. The documents and reports are partially 
described in figures to assist the reader. A flow diagram is being 
given in ilgure 6-1 and Figure 6-2 to show the data transforma- 


tions 
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oPigure 6-1 

P sor's View of Overall Inf orm .tlon Pl ow 
(continued in Figure 6-2) 




Gonfection-,ry orders 
for day after tomorrov/ 


Bread orders for 

- ’ tomorrow 



Updated standing 
orders 


Unavailable 
Confection ry orders 



for tomorrow 





l''i"’ure 6-2 

Uu er ’ s Vie-; o f Over.:.ll Inf ora, tion H oyj 
[C ontimod from Figure S-^Y~ 




Comiiiodity Sot 



Bills f 



Roimd 

Numbers 



Pre-print-- 
ed cmend- 
ment forms 



Data transformation 



Data set 



Do.ta set only referenced 


Versions of a data sot 
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VAN LOADING SCHDDDIE DOR 27 MRCH T'\GE 13; 

DELIVERY BAY ROUND COIflODITY CODE i DDSORIPTION QUANTITY 


1 A 18 001 13/4 LB THIN SLICED 57 

1 A 18 002 13/4 LB THICK SLICED ‘104 

1 A 18 

1 A 18 

1 B 20 



EOR EACH DAY 

REPORT VAN-LO/EING-SCHEDULE 

EROM DATA SET DESPATCHED-OEDER : S OP TOMORROW CALLED ORDER :S 
POR EACH ROUND OP ORDER :S, ASCENDING BEGIN 

POR EACH DELIVERY-NO OP ORDER :S, ASCEPIDING BEGIN 
POR EACfl COIflIODITY OP ORDER :S BEGIN 
POR NE\7-PAGE BEGIN 

VAN-LOAD-HEADING, TOMORROW (DAY OP IIOIEPH BY ITOMBER , 
MONTH OP YEAR BY NAME), PAGE-NUt/IBEn 
NEW-LINE, "DELIVERY BAY ROUND", 

"COMMODITY CODE & DESCRIPTION QUANTITY" END 
DELIVERY-NO, BAY-NO, ROUl^D, GOIflODITY. 
COMiODITY-DESCRIPTION, TOTAL OP QUANTITY END 
PORI'IAT 'WAN LOADING SCHEDULE POR" PAGE-NUI-IBER PROM 45, 

DELIVERY PROM 4, BAY PROM 10, ROUND PROM 16, COIEIODITY PROM 20, 

COMIODITY-DESCRIPTION PROM 26 , QUANTITY PROM 45 

OVER 
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BAKERY LOADIFG SCHEDULE EOR 27 I/L'JRCH PAGE -j 

DAY-LOADING 

jcOIffllODITY CODE & DESCRIPTION BAY 

028 THREE IN ONE A 

B 
C 
D 
E 
E 

TOTAL 

031 SNOOPY SmL PASTRY A 

B 

EOR EACH day' - - — 

REPORT DAY-BAICERY-LOADING PROM DATA SET 
CUSTOI'IER-DELI’VERY-CONEECTIONARYrS OE DAY AFTER TOHORROY 

FOR EACH COIMODITY OF CONFECTIONARY-ORDER ;S CALLED ORDER :S BEGIN 
FOR (l TO 6) LINES BEFORE EHD-OF-PAGE BEGIN 

HEAEING, TOMORROW (DAY OF IIONTH BY NUI'/IBER, MONTH BY NAME) 
PAGE-NUMEER, NE?/-LINEj 'DAY LOADING", NEW-LINE 
"COIMODITY CODE & DESCRIPTION BAY QUIJJTITIES" END 
NEW-LINE, COmODITY, COMMODITY-DESCRIPTION 
FOR EACH BAY BEGIN 

BAY, TOTAL OP QUANTITY OP ORDER :S AS BAY-TOTAL, NEW-LINE END 
TOTAL-HEADING, TOTAL OP QUANTITY OF ORDER :S AS COIMODITY-TOTAL END 
FOaRT HEADING FRCM 10 VALUE "BAKERY LOADING SCHEDULE FOR" 

PAGE-NUMBER FROM 45, COIMODITY SIZE 3, OOIMODITY-DESCRIPTION 
PROM 10 SIZE 20, BAY FROM 25 SIZE 1, BAY-TOTAL FROM 30 
SIZE 4, TOTAL-HEADING FROM 23 SIZE 5 COMMODITY-TOTAL FROM 
29 SIZE 5 OVER 



QUANTITIES 

4975 

4168 

3430 

1800 

2445 

903 

17721 

1970 

3 
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BMERY LO.YDISrG SOHEDULE FOR 27 Mt\RGH 

night-lo;dirg 

COMODITY COUE & EESGRIPIIOF BAY 


PAGE i 

i 

QUANTITIES | 


001 1 3/4 IB THIN SLICED 


002 1 3/4 IB THICK SLICED 


A 

B 

C 

D 

E 

E 

TOT/iI 

A 

B 

C 


3975 
1168 
4430 
2440 
1800 
304 
171 22 
1790 
4 


POR E/iCII DAY 

REPORT NIGHT-BAKERY-IOi'iDIIG SAKE AS DAY-BAKERY-IOADIITG REPORT 
USING (GUST0T.!1ER-DELIVERY-BEEAD;S OP TOMORROW 
POR CUST0IvIER-rEIIVERY-C0HPECTI01L\RY:S OP DAY APTER TOMORROW, 
’WIGHT-lOADtUG" POR 'DAY-IOADING") 

OVER 
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DELIVERY ROTE EOE 27 MARCH PAGE 1 


ROUND 

NO 

GROUP 

BRANCH 

COIMODITY-C ODE 
& DESCRIPTION 

QUANTITY 

DELIVERY 

18 

29 

004 

001 13/4 LB THIN SLICED 

57 

1 

18 

29 

004 

005 3 1/2LB SAND'TICH 

20 

1 



EOE EACH DAY 


REPQgr DELIVERY-HOTE 

despatch^soiejs op tomorrow 

POR Ei'^CH ROUND-HO, ASCEMDIHG BEGIN 

POR EACH (group, BRAKJH, COMODITY) ASCENDING BEGIN 
POR NEW-PAGE BEGIN 

NOTE-HEADING, TOMORROW (DAY OP MONTH BY NUMBER, MONTH BY NAME) 
PAGE-NUIABER, NEY/-LINE, PAGE-HEADING, NEW-LINE, HEADING- 2 END 
*EOUlTD-NO, GROUP, BRANCH 

COIMODITY, COIflODITY-DESCRIPTION, QUANTITY, DELIVERY END 
POEMAT NOTE-HEADING VALUE "DELIVERY NOTE POE" PROM 15, 

PAGE-HEADING VALUE ’ROUND-NO GROUITD BRANCH COIMODITY CODE"- 
-" QUANTITY DELIVERY", HEADING-2 "& DESCRIPTION" 

PROM 46, ROUND-NO SIZE 2 PRai 2, GROUP PROM 9 SIZE 2 BRANCH PR(M 13SIZE 3, 
COIMODITY PROM 19 SIZE 3 CCMMODITY-DBSCRIPTION PRai 23 SIZE 20 QUANTITY 
PROM 43 SIZE 2, DELIVERY PRCM 50 SIZE 1 OVER 


Data selc3Ction is based on day as a tine cycle. 

* This report can acconodate only one dispatch note for a day, 
for a given ROUND-NO, GROUP, BRANCH and COIMODITY and it can 
be an integrity constraint of the system. 
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mUlTEE BAKERIES BID 

RaUH]3~¥o. YffiEK/BAY RaDif]>li'o~~WBEK fo DilY HO CODE 


27 23 ERI - - . 

(PREPRIIEDED EORM^ 



EOE EACH vfeEK- - ' " 

ilCPORT OHDER-AlffliroJCEilTS-EOR-BEEAS EROM DATA SET ROOTI^imflBER 


l i'OR Ei'iGH ROUl'ID-HO ASOEroiHG BEGIH 
POR EACH DAY OP V/EEK BEGIIJ 
POR 50 TII.es BEgEH 

NEW-PAGE iiPTER 5 DHffiS 

ROUiJD-HO, MEEK OP YliAR BY FDIIBHl, DAY BY 1IAI.E, 

*E0I]17D-C0DE, VEEK-CODE, DAY-CODE, ITEf.I-CLASS EITD 
EOmiU'iT ROUHD-NO PR 0.1 6, WEK PROM 11 , DAY PROM 14, RODED-CODE PROM 18 
SIZE 6, WEE-CODE PROM 24 SIZE 6 DAY-CODE PROM 30 SIZE 3 
ITEM-CMSS VALUE ZERO SIZE 2 PROM 34 OVER 


POR EACH WEE 

REPORT ORDER-iyiENDEMEETS-POR-CONPECTIOlvr/iRY-l SAI.E AS 
ORDER-i'JIEHDPlEKCS-POR-BRE/i.D REPORT USIHG ( '' POR ITEia-CLASS) OVER 

POR EACH WEE 

-1-EPnRT nRDP,R-AmroL1EHTS-PCR-G0IjIPECTI0HiJlY-2 SAME AS 
ORDER-AMEiroiffilHS-POR-BREAD REPORT USIITG ( "- ''POR ITEM-GLASS ) Qj m 

POR EACH WEE REPORT 0RDER-AI>'iEEDMElTS-P0R-C0PPECTI05FARY-3 

SAIffl AS ORDER-'/IIElIDMElTTS-POR-BRE/iD REPORT USIHG ("“ ” POR ITEM-CLASS j OIM 


*EncDding data transformations are needed for this 
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GOIMODITY 

CODE 

100-1 25 


SALES REPORT EOR AGGREGATE COMMODITY 
WITH INDIVIDUAL CUSTOMER GROUPS 
AND IMIVIDUAL YfflEKLY VALUES 

RANGE 

PAGE 1 

CUSTQIBR 

GROUP 

\TEEK^5 

YffiEK 6 

WEEK 7 

yfESK 8 

10 

11603 

10243 

9178 

8413 

12 

6451 

5218 

4421 

4845 

15 

782 

660 

1199 

993 

16 

1395 

921 

996 


22 

536 

680 

770 

' 

25 

129 

230 



26 

488 






DOS EACH MONTH ' ; 

lOSPOBT SALES-OVER-HEEKS EROM DATA SET DELIVERED-0RDEEED:S OP YZEEL-SET-1 

SUB-REPOET-1 REPORT 

EOR EACH COmODITY-SBT BE&m 

HEW-LII'JE, SPACE 2, CafflODITY-GODES (SIZE ?) 
li^OR EACH GROUP ASCEllDIIG BEGIN 
GROUP 

EOR EACH \TEEK-0E-DEIIVERED-0ra3ER:S, ASCENDING (4 COIUIWS OE 
ft SIZE 16 EROM 36) BEGIN TOTAL OE QUANTITY EM 
NEW-LIlffi 

EOR NEY/-PAGE BEGIN 
SUB-REPORT-I PiEPORT 
NEW-LINE, ■\;QOmiOIilTY-SET ® 

EORM*! COMODITY-SET ERai 2 SIZE 7? GROUP EROM 14 SIZE 2 TOTAL EROIi 
10 SIZE 6 OVER 


*\'fflEK- SET-1 is a user invented time duration, to be described. 

flf group number continue on a new page then C GMODITY-SET is to 
be repeated once more, 

tfl^ultiple instances of data may be formatted vertically or horlzont^y. 
Eor horizontal formatting a page may be divided into repeating columns. 
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'TJJ POICT SUB-ilEPORT -1 PRM Dj'.TA SET MIL 
IPIL NEW-PAGE BEGin 

ELAI'IK Pj "SAEES REPORT EOR .ISGEEGATE COIfiODITY lAuTGE” 
SP/OE 10, PAGE-RDlffiER, NE'.7-IIKS, SPACE 14, 

'TOH IiroiVTDUAIj CUSTOMER GRCDPS", ^lEW-LIlffi, SPACE 16, 
"Airo ILDIVIDITAL T/EEKLY VALUES" IIEV-LII'TE, SPACE 2, 
"COmODITY CUSTOIffiR \®EI<5 VJEEK6 V.EEIC7 PEEKS " 

UEV/-LI1CE, SPACE 4 "CODES GROUP" EIUD 
OVER 


New page description being a lengthy description, is 
didficnlt to repeat and is described as a secondary- 
report which does not ha-ve an associated condition 
ior its production. 
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SALES REPORT FOR SEP/JIATE COIIilODITIES 

WTH INDIVIDUAL CUSTOMER GROUPS AND 

AND AVER/.GE quantities 

Pi.GE 1 

COMMODITY 

CUSTOMER 

AVERi'iGE OVER 


CODE 

GROUP 

MONTH 13-24 


104 

00 

156204 


104 

01 

30821 


104 

02 

14528 


108 

00 

1 1 6983 


108 

01 

1 240- 




mu EACH MONTH 

liEPQIlT COMIODITY-SALES EROM DATA SET DELITElTEID-OICDERiS OE MONTH-SET-1 
EON EACH COIEKDITY, ORUUE-NO, ASCENDING BEGIIT 
EOH NEW-PAGE BEGIN 

HEADING-I 5 PAGE-NUl'iiBER, NEW-IINE,HE/iDING-2 
NEV/-LINE,HE/vDING-3 END 
COL'MODETY 
GROUP-NO 

TOTAL OF QUANTITY END 
FOrSflAT 

lIEi'.DING-l VALUE "SALES REPORT FOR SEPARATE GOlffilODlTIES " FORMS 

IlEADING-2 FROM 10 VALUE "YffTH INDIVIDUAL CUSTOI'EE GROUPS" 

lIEADING-3 VALUE "AND AVERAGE QUANTITIES" FROM 15 COMIOUTY SIZE 3 FROM 9 

GROUP-NO SIZE 2 FROM 19 TOT/JL SIZE 10 FROM 24 

OVER 
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HOITTHLY INVOICE 

IFVOICE EQi 3335 BILLS: 35 IllHOIi 

CUSTOLIER NAIflE : A.D. iCCHJ'iEL 


CUSTOM]® ADLLESS 
S.H. DATE 
1 5/3/77 

FOR EACH mouth"' 


: 29, STSEBT 5Q, 

LOiOOU 

CO!®IODITY ORDER AIIODUT 


1 3/4LB THIU SLICED 5 21 .00 




REPORT INVOICES FROM DATA SET BILL;S OP CURRENT MOUTH 
Pgi EACH CUSTOIER-CODE BEGIH 

mi/BER OF DATE ASCEILDIIG AS BILL-FDlffi® , CURRENT MONTH BY ILilE 
INCREMENT INVOICE-NO BY 1 
COUNT BILL:S AS BILL-COUNT 


NEW-PAGE, SPACE 10, 'MONTHLY INVOICE" NEW-LINE 
"II'JVOICE NO : " INVOICE-NO, " BILLS: "BILL-COUNT 
NKV-LINE, "CUSTadER N/EIE : " OUST (SdER-NAME 

NEV-LINE, "CUSTOMER ADDRESS : " ADDRESS-LINE-1 , 
NEY/-LINE, ADDPH;SS-LIHE-2, NEW-LINE, HEADING 
POR EACH BILL BEGra 


FOR NEV/-PAGE BEGIN 

"INVOICE NO: " IMOICE-NO 


NEW-LINE, HEADING END 
NEW-LINE, BILL-NUIffiER, DATE, CatlODITY 
QUANTITY, V.1LUE ETO 
NEW-LINE, 'HMOICE NO" IIVVOICE-NO, 

SPACE 3, "TOTAL" TOTAL OF AMOUNT 

FCEMAL IlIVOICE-NO SIZE 4, BILL-COUNT SIZE 2, 

CUSTCMER-NAMB SIZE 20, ADDRESS-LINE-1 SIZE 30 
AxDDRESS-LINE-2 SIZE 30, HEAxDING 

"s.N. date coimodity order amount " 

BILL-NUI'iIB® SIZE 2, DATE FRai 4 SIZE 8, COIMODITY 
FROM 14 SIZE 25 QUANTITY FROM 40 SIZE 2, VALUE 
FROM 44 PICTURE 99.99, TOTAL PICTURE 9999.99 OVER 
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PEEP ^ 'IITTES om TnnTTI'.fHllTT 
I HAPTEE BAIGEICES UD.. 

I 1 — —J 


/uffiNDI'IElITS 


POUM'D HO. liTEEK/DAY 


27 


23/EEI 


nOIWE-lIO 
CODE 


TffiEK-lTO 
OOEE 




DAY 

CODE 


CD 


OEDEPS: 

I 
i 


C E 

0 I 

DESCRIPTION ° 

J'j E 

TNNS PINITS. HUNDRED TENS UNITS i 

-2-1 -6-3-2-1 t3-2-1 43-2-1 A6-3-2-1 i ' 

QUANTITY 

HUNnRETYT'TTENS IINTTS M^D DAYlsl 

UOT'MiiM sliced 

. i 

1 1 -d-:3-2-i m-T-w-Ji-i<'-b 

002 SANDvUTGH 1 2P ' 

_6-3-2-1 -6-3-2-1 -6-3-2-1 -P-+t— M-T-T-H-P-S 

003 TINS 20P 

* m «•« 

004 LONG BATCH 23P 

005 BRO?® BATCH ... 

^ 


POP EACH DAY 

b OCUMBHT OlffiER-AIDcICIDIffiETS TO DATA SET TYPE-B1 :S 
POP Ei.CH 50 TYI-’E-BI ;S BEG-IE llEQUIPSD /ilD 
HEW-POiai, APTEP 5 DIKES 

IWm^D-NOj DEEK-KO, DAY-ITO, POEKD-KO-CODE, KEEK-KO-CODE 
DAY-KO-CODE, ITEM-CLASS, KEW-LIKE, GPCDP-COIE, BP.\TOIi-COEE 
POP EACH OP TYPE-B1 i BEGIN 
KEW-LIITE 

POP B-l-DATA = SPACE BEGIN UNPILLED, IGNOPE ^ 

POp- 3-1 -DATA NOT = SPACE BEGIN 
IffiQUinpD ALL, NEW-LINE 
WxKE COM/IOriTY-IIEE = LINE-NUMBER, 

QUANTITY-CODE, AMENDMENT-CODE, AlffiHDMENT-TIPE, 

AlffiNDMENT-DAYS END 

PORMAT ROUND-NO PRCM 5 SIZE 2, V/EEK-NO PROM 10 SIZE 2 YALUE CURRENT 
VIEEK OP YEAR BY NUMBER, DAY-NO PROM 1 2 SIZE 3 YALUE CURRENT 
DAY BY NAME ROUND-NO-CODE PROM 17 SIZE 6 TOEK-NO-CODE PROM 
23 SIZE 6, DAY-NO-CCDB PROM 29 SIZE 3-ITEM-CLASS PR® 32 SIZE 2 
GROUP-CODE PR CM 17 SIZE 6 BRANCH-CODE PROM 23 SIZE 6 
QUANTITY-CODE PROM 17 SIZE 12 AMENDMENT-CODE PROM 29 
SIZE 1 , AMENDDIENT-TYPE PROM 30 SIZE 2 AMENDMENT-DAYS PROM 32 
SIZE 6, B-l-DATA PROM 17 SIZE 21 

um 


PAYIMTS-EEGEITOD 


ACCOUNT-NO 

15 


GLASS-OP-TMNSAGTION DATE AHOUIT 



poll EACH MONTH 

EOCUlffiNT PAYlffiNT-RECEIVED TO EATA TYPE-® 

POR EACH 15 TYPE-B5 :S BEGIN 

NEY/-POEM, ilPTER 3 LINES 
POR EACH TYPE-® BEGIN 
NEW-LIinil 

POR B5-DATA = BLANK BEGIN UNPILIEE, IGNORED ^D 
POR ®-DATA NOT = BLANK BEGIN 

REQUIRED AIL, ACCOtETT-NO, CD ASS- OP-TR\ FACTION 

TiA'TITn AMOOTT MID 

POriLlT B5-DATA PROM 2 SIZE"26, ACCOUNT-NO PROM 2 SIZE 
CLASS-OP-TRANSACTION PRai 9 SIZE 1 VALUE RANGE 1 TO 6, 

SIZE 6 VALUE (ZERO TO CURRENT DATE) AMOUNT PROM 18 PIC 999.99 V/DUE 

NUCffiM OVER 


Fon '’jACii day 

DOCUIIENT RETURN-ADJUSTMENTS SATE AS ORDER-A3.IENDMENTS 
DOCUMENT USING (NIL POR AMENDMENT-CODE, TYPE-3 PO-J-i TYPE-1 J 


OVER 
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DATA-DESGRIPTION 


DnH/iD-OlIDER : S PEPIMUD ^ OEDER :S 
CONEECTIONARY-OEDER; EEPIMEB AS ORDER ;S 
OVER 


DATA-DESCRIPOIIOIT 

PERIOD VJEEK-SET-1 IS EROM 8 WEEKS BEE CEE OURREM'-YiEEK 

10 4 WEEKS BEEORE CURRENT-i^EK 

OVER 


DAIA-DESCRIPIIOISf 
EOR ORDER :S BEGIN 
EOR EACH ORDER BEGIN 
EOR COlvMODITY OE Ol'ffiER 
l'/L\KE COIfflODITY-SET - 
EOR Ca'fflIODITY OP ORDER 
BITJ® COliMODITY-SEI = 

OVER 


^ 1 00 OR 1 25 BEGIN 
"100-125" ^ 

>125 BEGIN 
"125-165" EBD 


DAIA-DESORIPTION 

PERIOD MONTH-SET-1 IS PROM 24 JIONTHS BEEORE CURRENT-MONTH 

TO 1 2 MONTHS BEFORE CURRENT MONTH 
OVER 


COIEIENT: There is very conplicated decoding of ORDER forn 

Q-nd therefore the next few data description modules 
happen to be mostly procedures. 
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DATA-l'ESCniPTIOH DEGODIHG-OEDERS PROM DATA SET TIPE-B1 -OF TODAY 
FOR EAGH TYPE-B1 ;S BEGIIT 

SAI.CE ^ BIR;IIY 'daTA-DE SGRIPTIOB USDIG (ROIMD-RO-GODE FOR GODE, 
ROUND-NO FOR VAIUE) 

SAW AS BINARY DATA-DES ORIPTI ON USING (''JZEEK-NO-OODE FOR GODE, 

VZEEK-NO FOR V/iLUeI 

SAME ^ BINjiRY DATA-DESCRIPTION USING (DAY-NO-CODE 
FOR GODE, DAY-NO FOR V/iBUB) 

SAM, ^ BINARY DATA-DESGRIPIION . USING (iTEM-GLASS 
FOR GODE, ITEM-NO FOE VALUE') 

MAKE GROUH-NO = 0 

SAm AS GODE- 21 DATA-DESCRIPTION USING (POSITION 1 TO 2 OF GROUP-CODE 
FOR CODE, GEOUP-NO FOR VALUE) 

Sim ^ CODE-6321 DATA-DESCRIPTION USING (POSITION 3 TO 6 
OF GROUP-CODE FOR CODE, GROUP-NO FOR VALUE) 

MAKE BRANOH-NO = 0 

SAIffi AS CODE-321 DATA-DESCRIPTION USING (POSITION 1 TO 3 
OF BrjiNCH-OlDE FOR CODE, BR/iHCH-NO FOR V/DUE) 

SAME ^ CODE-321 DATA-DESCRIPTION USING (POSITION 4 TO 6 
OF BRANCH-CODE FOR CODE, BRANOH-NO M VADUE) 

Sim AS CODE-6321 DATA-DESCRIPTION USING (POSITION 7 TO 10 OF 
BRANCH-CODE FOR CODE, BR/iNCH-NO FOE VALUE) 

HAKE QUANTITY = 0 

SAJffl AS CODE-6321 DATA-DESCRIPTION USING (POSITIOF 1 TO 4 OF 
QUANTITY-CODE FOR CODE, QUANTITY FOR VALUE) 

SAI/nS AS COEE-6321 DATA-DESORIPTI ON USING (POSITION 5 TO 8 OF 
QUANTITY-CODE FOR CODE, QUANTITY FOR VALUE) 

SAME ^ CODE-6321 DAiTA-DESGRIPTION USING (POSITION 9 TO 1 2 OF 
QU/iNTITY-CODE FOR CODE, QUANTITY FOR VALDE) 

CREATE DEC0DED-B1 (ROUND-NO, UEEK-NO, DAY-NO, ITEM-NO, GEOUP-NO, 
BIUINCH-NO, quantity) 

END OVER 


COfflCENT: Reference to a part of a data item can be made by POSITION. 

The same data could ha^e been described in the input document 
by using a number of data names, to avoid a partial reference. 
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D/iTA-DESCRIPTI^H BINARY 
M/iKE VALUE = 0 


EOR POSITION 1 of CODE = 
FOR POSITION 2 OF CODE = 
FOR POSITION 3 OF CODE = 
FOR POSITION 4 OF CODE = 
Fai POSITION 5 OF CODE = 
FOR POSITION 6 OP CODE = 
OVER 


1 BEGIN ADD 32 TO VALUE END 
1 BEGIN ADD 1 6 TO VALUE ETO 
1 BEGIN ADD 8 TO VALUE ETO 
1 BEGIN ADD 4 TO VALUE MD 
1 BEGIN ADD 2 TO VALUE ETO 
1 BEGIN ADD 1 TO VALUE El© 


DAxTA-DESCRIPTION CODE-6321 
MICE C lECK = J 

FOR POSITION 1 OP CODE = 1 BEGIN AiDD 

FOR POSITION 2 OF CODE = 1 BEGIN AiDD 

FOR POSITION 3 OF CODE = 1 BEGIN ADD 

FOR POSITION 4 OF CODE = 1 BEGIN ADD 

ADD CHECK TO VALUE OVER 


6 TO CHECK END 
3 TO CHECK ^ 
2 TO CHECK ^ 
1 TO CHECK El© 


DATA-DESORIPTION GET- VALUE 

FOR CHECK < 1 0 BEGIN IIULTIPLY CHECK. BY 1 0 

ADD CHECK TO VALUE END 


OVER 


DAxTA-DESCRIPTION CODE-321 
FAKE CHECK = 0 

FOR POSITION 1 OF CODE = 1 BEGIN AxDD 3 TO CHECK MD 

FOPi J.OSITION 2 OF CODE = 1 BEGIN AiDD 2 TO CHECK ^D 

li'OR POSITION 3 OF CODE = 1 BEGIN AxDD 1 TO CHECK END 
SAH'iE ^ GET-VAxIUE DATA-DESCRIPTION 
OVEFx 

DATA-DESORIPTION CODE- 21 
MKE CHECK = 0 

FOR POSITION 1 OF CODE = 1 BEGIN ADD 2 TO CHECK END 

®R POSITION 2 OE CODE = 2 BEGIN ADD 1 TO CHECK END 

'SAffl GET-VADIE DATA-DESORIPTION 
OVER " 


DATA-DESCRIPTION C ODD-63 211 , , 

SAil"^TbDE-6321 DATA-DESCRIPTION USING (NIL FOR i©D CIIECK TO ViLUEJ 
Sim AS GET-VALUE DATA-DESORIPTION 
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DATA-DESCRIPTI OH DECODING-THE-DAY-AUD-C Cl'f lODITY-CODE 
EOH DEC0DED-B1 :S, COMtlODIDY-SET :S BEGIU 
EOR EACH DEC0DED-B1 BEGISF 

EOE AI.!EEDEMT-TYPE ^ '1 1 " BEGIH 

^OR DAY-NO = CURRENT DAY ON WEEK BY NUMBER BEGIN 
EOR WEEK-NO = CURRENT YJEEK OE YEAR BY NUIffiR BEGIN 

DOR COIMODITY-SET (ITEM CLASS = ITEM-CLASS OE LECODED-BI , 
C ailODITY-LINE = COMMODE TY-LIIE OE DECQDED-BI ) 33 GIN 
GOIMODETY = CD MODI TY OP COIfflODITY-SET 
EvEDESCEIBE /RIENDMENT-DAYS BEGIN 
AMENDMENT-DAY REPEATED 6 TliffiS END 
NUMBER . DEC0rED=-B1 DAY-COUNT , ^ 

EOR EACH DEG0LED-B1 BEGIN EOR AMENDMEHT-Di ^ 0 BEGiD 

CREATE ACCEPTED-AMENDMENT (DAY-COUNT ) 

END OVER 


COI.ECENT: Besides the DAY-COUNT the other data itens associated vsith ACCEPTED- 
A1.CEHDI.CENT are being assumed by the user, for the time being. 


DATA-DESCRIPTI ON NIL 

EOR ACCEPTED-/J!/[EHDJIENT:S OE CURRENT DAY BEGIN 
EOR EACH ACCEPTED-AMENDMENT BEGIN 

EOR MENDMENT-CODE = "1 " BEGIN CREATE PERM/'iNENT-AIENDMElEE ^ 
EOR AI/nUNDlENT-CODE = 0 BEGIN CREATE TEMPOPUJiY-AMENDMENT END 
OVER 


COMMENT: The ACCEPTED-AMENDMENT at tliis point has two tine tags. It is 
today's amendment because it'»lbeen accepted today. Also, it 
may be an amendment for a Eriday order. This second time tag 
is kept as a data item DAY-CCDNT in the description. 


^Repeating 
for other 


of the field creates a set of 6 DECODE I^BI , 
processing statements at this level. 
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DATA-ijESOBIPTIOU UPDATIHG-STAEIEING-OnEERS 
POP PEmiAEElTT-AlvIEm'lESrTS, STAHDING-OPiDEEtS BEG-IH 
POP EACH PERI'PINEtW-AI'EEKDT'ffiNT EEG-IE 

POE STAHDIIG-ORDEE (GEOUP-GODE, BrJETOH-CODE, GOIffliOBlTYS 
DAY-GOUM = ALL OP PEHttlTEIW-AIIEroLW BEGIIT 
POE STANBING-ORDEE PRESENT BEGIN 
POE AI.IEKDMENT-GODE = "lO" BEGIN 

MKB QUANTITY = QUANTITY OP STANDIITG-OEDER 

ADD QUANTITY OP PElPMNENT-Al'ffiHDTffiNT TO QUANTITY EED 

POE AIfflNDl'IENT-0 (DE = "01 " BEGIN 

POE QUANTITY OP PEEI/IANEJTT-AI'ffilDIfflNT 
QUANTITY OP STAHDING-OPJ)ER BEGIN 
MKE QUMTITY = QUANTITY OP STANDING-ORDER^ 

SUBTEAGT QUANTITY OP PEra/IANENT-AI'lEm'/lE]}lT PHOU QUANTITY 
END END 

POR AMEITDMENT-OODE = "00" BEGIN 

MAZE QUANTITY = QUAiNEITY OP PEriUJIENT-AIIENDTIENT END 
*UPDATE ST/JIDING-OEDEE (QUANTITY = QUANTITY) 

END 

POE STANDING-OIfflEE AJ3SENT BEGIN 
POR AI'iEENDMENT-OODE = "00" BEGIN 

GPEATE STANDING-ORDER (QUANTITY, GEOUP-GODE, BRi\NCH-GODE, 
OOIMODITY, DAY-GOUNT = ALL OP PEEI-IANENT-AIvIENDl/IElOT ) END 

OVEE 


GOMIENT: The presence and absence of standing orders is checked here 
because the actions are specific. The user nay forget to 
describe what is to be done in case of absence generally. 


* QUjJJTITY at the right hand side nay be of PEKiIANENT-Ju.IENDlviii.lTS 
or of STANDING-OEDEE. 
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OH CIlEATING-THiPOrLiffiY-OrDEIlS SAiE ilS UPDATING STANDI FG-OADEDS 
gat A-DESCHIPTI on using (TH'.IPOE/'iEY-AJ'MIDI'CENT 
FOR PEmNENT-AMENDIffiNT, 

CREATE TEMPORARY- ORDER POR UPDATE STANDING-ORDER, 

GRE/iTE TEt£POR/.RY ORDER FOR CREATE STANDING-ORJCER) 

OVER 


DATA-DESCRIPTION TEB.a?OR/IlY-ORDER-H/.miNG 
l^ERIOD DAY OE VffiEK BY NUMBER IS DAY-COUNT, 

OE TEIIPORARY-ORDEE 

PEiaOD TOEK OE YEAR IS CURRENT lEEIC, OE TH/IPOrLi\RY-ORDER 

PERIOD YEAR IS CUIEiENT YEAR, OE TEHPOEARY-OEiDER 

PERIOD DAY OE TOEK BY NDlfflER IS DAY-COUNT, OE STANDING-ORDER 

OVER 


COIvEIENT: Tho Ijine tag declaration here specifies tvvo things - 
1 . It converts a data iten DAY-COUNT to tine fag 
2. On standing orders the tine te^ is only vathin 
a weelcLy cycle and dtiovv's that Monday’s orders 
heccne today's orders every Monday. This is not 
so for tenporary orders which exist only one Monday. 
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SATA-DESCIIIPTIOU HKDS-OP-STAHIin'IG-OKDEES 
EOR STAroiNG-OEDEEsS BEGIN 
Foil C aMODITY < 1 0 BEGIN 

ST/ilIDING-ORI)ER;S DEFINED AS BEEAD-STASDING-OnDER:S mD 
I^R COMMODITY ^10 BEGIN 

STANDING-ORDER :S DEFINED AS CONEECTICNARY-STANDING-ORDEE :S 

OVER 

DATA-DESORIPTION EINDS-OF-TEtiD?OIGmY-OEDEES 
FOR TEMPODJJlY-ORDEEiS BEGIN 
FOR COMMODITY < 1 0 BEGIN 

TED/rPOlAIRY-ORDERS EEFINED ^ BREAD-TEE', CPORARY-ORDER :S ^ 

FOR COMMODITY > 10 BEGIN 

TEMPORARY-ORDER : S DEFINED AS COHFECTI ''NARY-TEI'IPOR/iRY-ORDER : S 

END 

OVER 


DATA-DESORIPTION PPuEP/IlING-ORDERS-POR-BREAD 
FOR EACH DAY 

F_gR BRE/'iD-TEMPORARY-OnDER:S OP TOMORROW, 

BREAD- ST/J'IDING-ORDER-.S OF TOMORROW BEGIN 
FOR E/iCH STANDING-ORDER BEGIN 

FOR BREAD-TEI‘,D?OR/.RY-ORDER (gROUP-CODE, BPRiNCH-CODE, 
COMMODITY = AIL OF BRE/iD-STANDING-ORDER) BEGIN 
FOR BRE/*D-TEl\n?ORARY-ORDER ABSENT BEGIN 

CREATE BREAD-ORDER (AIL OF BREAD-STA.NDING-OEDER j 
PERIOD OP BREAD-ORDER IS T0MOREOW 
END END END 

PCE E/iCH BREAD-TEMPOR/.RY-ORDER BEGIN 

CRE/iTE BREAD-ORDER (AIL OF BREAD-TEC, 9P0EAiRY-0RDER) 
PERIOD OP BREAD-ORDER IS TOMORROW 

OVER 


DAiTAi.-DBSCEIPTION PREPi'RING-ORDERS-FOR-CONFECTI^'NARY 
SAI.CE AS PREPARING-ORDERS-FOR-BREAD DATA-DESCRIPHON USING 
TmY after TOMOliROY/ FOR TOMORROW, CONFECTIONAHY-OEDER 
FOR BREAD-ORDER, CONPECTIONARY-TBf.!n?ORARY-OEIER FOE 
miEAD-TEC,COEAiRY-ORDEE, 0 ONFECTI ONARY-STANDING-ORDEE 
FOR BREAD-STANDING-OEDER) OVER. 
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DETA-DESC lUPTI OH BnEAX^OiminS-TO-BE-DELII/ESED 
FOR BIlEiJ3-OrJ)En:S OP TOMOSBOW BEGIN 

BOB UNAVAIIi/iBLE-COMlODITYeS OE TODAY BEGIN 
EOB EACH HREAD-ORDETl BEGIN 

EOR OTAVAIL/iBLE-COItlODITY (C OIC'IODITY = C OMODIT Y-G ODE 

OP bread-order) begin 

EOR UNAVAIIABLE-OOIMODITY PRESENT BEGIN 

CREATE UNAVAILABLE-BRE/JD-OEDER (/JD OE BRDID-ORDER) 
PERIOD OP UNAVAILABLE-BREAD-OEDER IS TOIIORRON ETO 
EOR IfflAY/iILifflLE-CaMODITY ABSENT BEGIN 

CREATE CUSTCtlER-DELIVERY-BREAD = (A3Z. OE BEDAD-ORDER) 
PERIOD OE CUSTO]\IER-DEE.IVERY-BPlGAD IS TOI'IORROY END 

OVER 


COMMENT; At this point 'unavailahLe coramodities remain as a data for 
which no input is defined. Very low volume data often has 
no staixlard input forms. 


DATA-DESGR IP TI ON C 01R?ECTI ON/iRY-OriDERS-TO-BE-DELIVERJID 

^ Bilc/i-OIiDERS-TO-BE-DELIVERED DATA DESCRIPTION USING 
'Ccorai'ECTia'I/iRY-ORDERrS FOR BREAD-OEvDER jS, DAY ilETER TOIIOIffiON EOR TOIIORRON, 
OUSTOMEt-DELIVERY-CONEECTION/iRY FOR CUSTOIIER-DEIIVERY-HOEAD) 

OVER 


DATA-DESCRIPTION ROUND-DELIVERY-NOS 
EOR :’4CH DAY 

FOR CUSTa/IER-DEIIVERY-BEEAD:S OF TOMORROW C/iDLED ORDER ;S, 

OUST aiER-DEII VERY-CONFECTIONARY OE TOMORROW C.f11LED ORDER :S BEGIN 
EOR E/.Cn ROmirnNO OE ORDER :S, BEGIN 
M/JCE DEUVERY-NO = 1 
liJCE LOADING-SPACE = VAN-CAPACITY 
EOR EACH OiiDER BEGIN 

FOR SIZE-POINTS OE ORDER > LOADING-SPACE BEGIN 
INCREIffiNT DELIVEIY-NO BY 1 
JIAKE LOADING-SPACE = VAN-CAPACITY END 
DECliBASE LOi’DING-SPACE BY SIZE-POINT OE ORDER 

GRE^iTE DESP/RCHED-ORDER (DELIVERY = DELIVERY-NO j ALL OE ORDERS; 
period" op DESPATCH-ORDER IS TOMORROW, 

END 

OVER 


DATA-DESORPTIQN NIL 

UNAVAILABLI^BREiJ)-ORIOj]R:S DEFINED ^ DESPJiTCH-NOTm 
IINAVAILAELE-0DNEECTI01L\EY-0RDER:S DEFINED ^ DESPATCH-NOTE 
DESPATCHED-ORDER DEFINED AS DESPATCH-NOTE 
OVER 
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MTA-^ESCHPTIOn ILi^TUEIS-GHEOICEIG 

^ DL'CODINCr-OEDEAS DATA-DESCRPTIOU USING 
(lUE— E3 EOit TYPE-B1 j DEOGDED— B3 POE DECODED— B1 ) 

OVEE 

DATA-DESCillPTION DECODING-DAY-PCE-EETUENS 
SAI'gS AS DECODING-DAY DATA-DESCEPTIQN USING 

(DECODED-B3 POE DECODED-B1 , ACCEPTED-EEIUM POE ACCEPIED-iUIENDIffil^T ) 
OVEE 


DA'IA-DESCEIPIION PEEIOJU-OP-EETUEII 
POE ACCEPTED-EETUiaiS lOP TODAY BEGIN 

EAY-COUt'TT OP ACCEPTED-OEDEE = YESTEPJIAY OP YEEK BY iroi'IBEE BEGIN 
ACCEPTED-rJDTOEN DEPINED AS EETUEN END 
OVEE ^ “ 


CCM''IENT: Here day coint is not used to declare a period but fcsr data 

of 

oelcction. Period of EETUEN by default is that/AOOEPTED- 

IlDTUEN, It implies thot letums have to come ■within a day. 

DATA-DESGEIPTIO N UPDATING-DELIVERY 
POE 3E5TUEN:S POE TODAY BEGIN 

POE DESLViTCl-IED-OEIEE:S OP YESTERDAY BEGIN 
POE EACH ElETUHN BEGIN 

POE DESPATCHED-OiffiER (GEOUP-NO, BRANCH, COM-IODITY = ALL OP EETUl'U) 

BEGEIT 

POE DESPATCIIED-OEDEE PRESEIOT BEGIN 
POE AHElDlIENT-CaDE = '10'' BEGIN 

ADD QU/iNTITY OP RETURN TO QUMTITY OP DESPaTCIIED-ORDEE 
GIVING NEW-QUANTITY 
POE AUENDIIENT-CODE = "01 " BEGIN 

POE QQAITTITY OP DESPATCHED-ORDEE NOT < QUANTITY OP 
RETURN BEGIN 

SUBTRACT QUANTITY OP PiETiniN PROM QUMTITY OP DESPATCiED-OEDER 
GIVING NEW-QUANTITY ^ 

END 

CREATE DELIVEEED-ORDER (QUMTITY = NEY/-QUANTITY, ALL OP 

DESPATCHED-OrLDER ) 

PERIOD OP DELIVEEED-ORDER IS YESTERDAY END 

OVER 


COMffiNT; In the above description, from todayfe returns, yesterday's 
corrected DELIVEEED-ORDERS have been created. 
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DATA-DESGRIPTIOU PDIAL-DEIjllZERED-ORIEES 

despatghed-oreeris op yesterday, 

DELIVERED-ORIER:S OE YESTERDAY BEGII 
EOR EAGH DESPiYDGHED-ORDER BEQ-Il 

DELIVERED-ORDERiS ( GROUP BPl&NGH, GOIMODITY 
= ALL OP DESPATGH-ORDER) BEGIN 
DELIVERED-ORDER ASSENT BEGIN 
G REATE DELIYERED-ORDER = (ALL OP DESPATGBED-ORDER ) 
END 

OVER 


POR EAGH MONTH 

DATA-DESGRIPTION GPLATI ON-OP-BILL 
POR DELIVERED-OEDGRrS OP GURRENT MONTH," 

GOIMODITY-SET;S BEGIN 
POR EAGH GOMODITY-SET BEGIN 

POR DELI"VERED-0RDERS (gOIMODITY = GOI'DIODITY-CODE OP GOMIODITY-SET ) 

BEGIN 

POR EAGH DELIVERED-OPiDER BEGIN 

MULTIPLY QUAIWITY OP OPiDER BY PRIGE OP 
GOMODITY-SET GIVING AMOUNT. 

CREATE BILL (AMOUNT = AMOUNT, ALL OP DELI VERED-ORDER ) END 

OVER 


END-OP-DESGRIPTI ON 


COMMENT; CCSffilODITY-SET is also used as a 
domain elsewhere. 


6-3. CONCLUSION 

This case study has a fairly complicated timing requirement and 
data selection. It also requires a lot of calculative description due 
to the need to decode forms. It has very special requirement in terms 
of timings. 

The description shows that it is possible to describe all the 
necessary aspects of a real life information system without making 
use of caaments or host language procedures. Such a statement can be 
used for the analysis of data requirements etc. 
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GONGLUSIOIS 

Inf orcntion systen design for o-dnLnistmtive systcjns lias alTO.ys 
taken enornous tine end nan-po?jGr. Most often, the reason for this is 
a corxiunication gap between the user and the systen anolyst, created 
by an inadequate description of the user's problen. Eiis caJUs for 
nany iterations during various piases of the systen developnent cycle. 

Ihc probleu of reducing the tine and efforts required for the infoma.- 
tion systen. developnent has been taken up in this thesis, Hie nain 
idea is to introduce the conputer as a tool, in the systen developnent 
cycle . 

A lot of work is being done in this direction. Systens like 
ISDOS and HICTC., SYSTEM-1 BOTTOM PART etc., are sone of the systens, which 
lu'.ve tried to achieve this, by taking up the autonation of the design 
pha.so as the nain task. Autonation of problen a,cquisition phase is 
being tried in two different ways t one is that of describing the 
functions cf the organisation, and the other is that of using languages 

with tuple-oriented data, selection. 

In this thesis a high level language is developed for describing 
infomation processing systens. This language has features for des- 
cribing the inputs, outputs, data transf omations and systen tinings 
with the help of data oriented control structures. It is shown that 
business processing systens can be conpletely described in this language 
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vd-thout the help of procediires vTritten in host longuoges, i\ll the 
features of this languo^e are based on two underlying concepts. 

1. User shtould be allowed to specifically describe all the 
interactions of the infomation processing systea, vdth his organi- 
sation. Ihi s infoma.tion could be such as update tinings or instruc— 

tionsfor picking up line nunbers fron a docunent to be used as product- 
codes, 

2, Business systens are ccncemed with classes of subsets of 
d.ata. MechonisQs of data selection and generation for such subsets are 
osGontirl for high level systen descriptions. (This fact has not been 
recognized in the existing literature. 

It is shown that algorithnic analysis of the kind, done by other 
systoni like ISDOS, con. be done on systen descriptions given in the 
language described in this thesis. The data needs can be identified 
and c.-n be notched with the data availability. It is also shovm. that 
real life systens analysis is mch more than nechanically checfcLrjg 
for the presence of required data itens. 

It is established that the block-structure of SH con be exploited 
to algorithm. cally analyse the systen description to generate questions 
about the systen f or doing the following : 

1 . To guide the user to give nore correct descriptions 
of the systen, 

2. To got design infomation freo the user related to 
data cardinality and integrity. 



117 


It is felt thcit to r.nalyse nnd design inf omniion systems, it 
is important to understand tlio purpose of data transfo mat ions. It 
has boon seen that in the model building approach, the descriptions 
bocouo a largo sot of smll concepts. Putting the pieces together, 
vd-thout a nechamsms for structuring, is very difficult. Purther 
work is to be done to work out better user interfaces. But they 
will be useful only viien data oriented structural descriptions and 
not property oriented descriptions are given. ITew concepts to 
czrrich the user interface vocabulary nay be developed- Hie concepts 
should bo abstracted in a manner usable fer data processing. Here 
wo have developed the subset concept. Sinilcrly an abstraction which 
could identify real entities is very much needed. In this thesis, 
tino has been abstracted to a usable level. Sinilnxly, a generalised 
concept for ’measure’ could bo developed. Hieso abstractions could 
make the level of the description less clerical and more managerial. 

It will also bo very useful if a generator could be developed 
which may not use very efficient design strategies but nay atleast 
create one feasible design and generate the desired information 


processing system 
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/j>PEroix I 


1 24 


100300 GRAI'fffin DEPINITIOIT. 

1 005 00 Giuumn-iD . nEPonr . 

100700 OPTIOIS IKE LIST FODES XREE COMPILE. 
100900 DEPIEE SIZE TEXT = 80 LYTES. 

101100 DEEIFE SIZE EFTITT = 30 BYTES. 

101330 DBPIIIE SIZE STACK = 9 EHTIES. 

101500 PBDCEDUES LIST. 

101700 DATA-KEED. 


1 01 900 
102100 
102300 
102500 
102700 
102900 
103100 
103300 
103500 
103700 
103900 
104100 
104300 

104500 
1 04700 
104900 
105100 
105300 
105500 
105700 
105900 
106100 
106300 
106500 
1 06700 
106900 
1 071 00 
107300 
107500 
107700 
107900 
108100 
108300 
108500 
108700 
108900 
1 091 00 
109300 
109500 
109700 
109900 
1 1 01 00 
1 1 0300 
110500 
100700 
110900 


EEMOVE-LI, 

ElffiOR-EOUTIllE 1 P/JMMETERS, 

EESOn-TEifflUFATE, 

YALUE-OE-DI, 

PLACE- OE-LI, 

MATCH-DI, 

SAVE- VALUE, 

SAVB-POSITIOF? 

INCREASE-LEVEL, 

RESET-POSITIOF, 

ENTES-DI, 

EFTER-DI-GEFSTlATED, 

EFTER-EILE-FAliE, 

LECEEASE-LEVEL . 

GRAPH SECTIOF. 

set-autoread-lihe(i ). 

BIG-QUAEY: ’EEPOET" GO TO mTA-DESCRIPTIOF 

ELSE ERR0R-R0UTIFE(1 ) 

EEROE-TEIMIFATE , 

EFD-OE-QUERY; LATA-HEED. 

% EASY TO USE SAVE-DI IFSTEAD OE ENTITY STACK. 
PL/EE-AFL-VALDE ; CLEIR-EFTITIES . 

REPEAT-LIFE: nTTERROGATE-STACK, 

"OVER” OR *EHI)^ SET-AUTOREAI>-LIFE(o), GO TO EFD-OE-QUERY. 
'VALUE” ELSE GO TO POSETIOF, 

^TOGGLE*- EISE ERROR-ROUT IFE (5 ) ; GO TO REPEAT-LIFE. 
*LITER/Ji* OR *IFTEGEE* SAVE-VALUE , RETURF-EFTITY, 
VALDE-OE-DI, SAVE-EFTITY, 

GET-EITITY ; GO TO REPEAT-LIFE 
ELSE EEKOE-nOUTIFE(3); GO TO REPEAT-LIFE. 

POSITIOF: 

"EROM” ELSE GO TO LIFE. 

*TOGGLE^ ELSE EEE 0 E-RaJTIFE( 6 ) | GO TO REPEAT-LIFE. 
*IFTEGER* SAVE-POSITIOF, RETURF-EFTITY, 

PLACE-OE-DI, SAVE-EFTITY 

GET-EFTITY, GO TO REPE/iT-LIFE, 

ELSE ERROR-ROUTIFE(4 ) ; GO TO PEPE/iT-LIHE. 

LINE: 

*T OGGLE^ EETURF-EFTI TY, 

EnR0R-R0UTISE(7 ) . 

*W0RD* MTCH-DI, 

ELSE GO TO LINE-END. 

-'*Sm 1 * SAVE-EFTITY, 

GO TO REPEAT-LIFE, 

ELSE SUPPRESS-EFTITY. 

LIFE-END; *ANY-YCRD^ ERROR-ROUTIFECs). . 



111100 


GO TO EEPEAT-LINE. 

111300 

DATA-DESCniPTION: 

INCEEilSE-LEVEL 

111500 


GO TO ilNY-TYPE. 

111700 

AIIY-TIPE: "BEGIH" 

SUPPEJSSS-ENTITY, GO TO NEXT-LEVEL 

111900 

"END" 

GO TO END-LATA-DESC . 

1 1 21 00 

"OVEE" OE *EHD* 

GO TO END-DATA-DESC 

1 1 2300 

'^OEMAT " 

GO TO PLACE-AHD-VALUE 

112500 

ELSE GO TO HEXT-NODE, 

1 1 2700 

EEPOET-MEDIM-ACTI ON : 


1 1 2900 

"NE\7-LINE" 

EESET-POSITION, 

113100 


GO TO ANY-TYEl . 

113300 

"NEW-PAGE " 

EESET-POSETION, 

113500 


GO TO /JTY-TYPE. 

113700 

SET-EUNCTION-DI : 


113900 

"COUNT" 


114100 


ELSE GO TO SET-SELECTION-ACTION. 

1 14300 

*woruD* 

ENTEE-DI, 

114500 


EL SE IIiIEOE-riOUTINE( 9 ) , 

114700 


GO TO ANY-TYPE. 

114900 

"AS " 

GO TO I'lEXT-NODE, 

115100 


ELSE EffllOR-ROUTIHE(lO) 

115300 


GO TO ANY-TYPE. 

115500 

*WOED* 

ENTER-DI-GEIELlATED, 

115700 


GO TO ANY-TYPE, 

115900 

EL SE EEEOE-EOUTINE ( 1 0 ) . 

116100 

GO 

TO ANY-TYPE. 

116300 

SET-SELECTI (XI-ACTION ; 


116500 

"POE" 

GO TO NEXT-NODE 

116700 


ELSE GO TO DATA-STEING. 

116900 

SUB-SET-SELECT ; "EACH" 

GO TO NEXT-NODE , 

117100 


ELSE GO TO GIVEN-VALUE-SELECT. 

1 1 7300 

"OF " 

ELSE GO TO UNQUE- VALUE-SUBSET, 

117500 

*WOED^ 

ENTER-EILE-ILYTE 

1 1 7700 


GO TO NEXT-LEVEL 

117900 

ELSE EEEOE-EOUTINECiI ) 

118100 


GO TO ANY-TYPE. 

118300 

UNIQUE-YAIUE-SUBSET : 


118500 

*wonD^ 

ENTEE-DI, GO TO NEXT-LEVEL 

118700 

ELSE EnE0E-R0UTINE(l1 ) 

118900 


GO TO ANY-TYPE. 

119100 

GtlVEN-VALUE^SELECT ; 


119500 

*W0ED^ 


1195 00 


ENTEE-DI 

1 1 9700 


ELSE ERPiOR-EOUTINECi 1 ) 

1 1 9900 


GO TO ANY-TYPE. 

1 20100 

ELSE 

GO TO IGNORE-EOR. 

1 20300 

*LITEnAL* GO TO NEXT-LEVEL. 

1 205 00 

IGNOEE-POE: 

REt.IOVE-DI, 

1 20700 


error-routine(ii ), 

1 20900 


GO TO ANY-TYPE. 

121100 

DATA-STEING: ^TOED* 

ENTER-DI, GO TO ANY-TYPE, 

1 21300 

ELSE GO TO 

1 NEXT-NODE. 

1 21500 

", " GO TO ANY-TYPE. 

1 21700 

*ANY-WOED^ EREOre-EOUTINE(l 2) GO TO ANY-TYPE. 



121900 lEXT-LEVEL : "BEGILI" 

1 221 00 else 

1 22300 

122500 EKD-DATA-DESC : 

1 22700 LABEL-1 : 

1 22900 

123100 PROGMH SEGTIOH. 


GO TO L'lDETj-l, 
EPJ10[1-E0UT1HE( 1 3 ) j 
GO TO lABEL-l , 
DECiaSASE-LEVEL, EXIT(i). 
PEriPOBM mTA-PESCHIPTIOlT 
GO TO AKT-TIPE. 


1 23300 IDEKTIEIOATIOH DIVISIOII. 

1 23500 PPOGnAM-IP. BIGQEY 
1 23700 ENVIEOmiEIT DIVISION. 

123900 COEFIGUPATION SECTION. 

124100 INPUT-OUTPUT SECTION. 

124300 PILE-CONTROL. 

1 24500 SELECT EEPSPC A.SSIGN TO READER. 

124700 SELECT DTNEED ASSIGN TO PRINTER. 

124900 DATA DIVISION. 

125100 PILE SECTION. 


1 25300 PD 

REPSPC . 




12:500 01 

EEC-IN 

PIC 

Z(80). 


1 25700 PD 

DTNEED. 




1S900 01 

0UT-rj3C . 




126100 03 

PILLER 

PIC 

Z. 


1 26300 03 

i'P^EAl 

PIG 

Z(32). 


1 26500 03 

AREA 2 

PIC 

Z(33). 


1 26700 03 

AREA3 

PIC Z(33). 


126900 04 AREA4 


Z(33). 


127100 WaRKING-STOEAGE SECTION. 


127300 77 

I 

PIC 

99. 


1 27500 "7 

J 

PIC 

99. 


127700 -7 

K PIC 

99. 



127900 '•7 

L PIC 

99. 



128100 '■7 

SAiVE-VAL 

PIC 

i Z(30). 


128300 "7 

SA.VE-POS 

PIC 

1 999. 


128500 "7 

DEEPEST-LEVEL 


PIC 99 

VAiLUE ZERO. 

1S700 77 

PIRST-DEEPEST 


PIG 99 

VAiLUE ZERO. 

128900 77 

LAST-DEEPEST 


PIC 99 

VAxLUE ZERO. 

129100 "7 

EEL-LV 


PIC 99 

ViALUE ZERO. 

129300 "7 

1 

\ 

0 


PIG 99 

VALUE ZERO. 

129500 ^7 

REL-DI-SN 


PIC 99 

VALUE ZERO, 

129700 n 

vroRK-i 


PIC Z(30). 

129900 '77 

TEXT 


PIC Z(80). ■ 

130100 77 

TEXT-OUT PIC 

Z(132). 


130300 01 

DATA-TAHLE. 




130500 

02 D-TiAHLE 

OCCURS 100 TIMES. 

1 30700 

03 D-SN 



PIC 99. 

130900 

03 D-NAlffl 



PIC X(30). 

131100 

03 D-LEVEL 


« 

PIC 99. 

131300 

03 D-N-POS 



PIC 999- 

131500 

03 D-N-POS-DI 


PIC 99. 

1 31 700 

03 D-VAL 



PIC X(30) 

131900 

03 D-TIPE 



PIC X. 

132100 01 

CUPlRENT. 




132300 

02 C-SN 



PlC 99. 

132500 

02 C-NAMB 



PIC X(30) 



132700 


02 

C-LEVEL 



PIC 99 . 

132900 


02 

C-NEXT- 

-DOS 


PIC 

999. 

133100 


02 

C-NEXT- 

-POS-AET-DI-NO PIC 99. 

133300 

01 

ER-MESSAGE, 





133500 

02 

ER- 

-1 . 





133700 

03 


EILLER 

PIC 

X(^) VALUE 

'NOT A REPORT". 

133900 

03 


EILLER 

PIC 

X(20) 

VALUE 

'*END DY DEEAULT 

134100 

03 


EILLER 

PIC 

X(2D) 

VALUE 

"VilLUE-INC arPEGT 

134300 

03 


EILLER 

PIG 

X(20) 

VALUE 

"VALUE IGNORED". 

1 34700 

03 


EILLER 

PIC 

X(20) 

VALUE 

"POSITION IGNORED 

134900 

03 


EILLER 

PIC 

X(20) 

VALUE 

'EODJlMT IGNORED". 

135100 

03 


EILLER 

PIC 

X(20) 

VALUE 

"TOED IGNORED". 

135300 

03 


EILLER 

PIC 

X(20) 

VALUE 

"COUira IGNORED". 

135500 

03 


EILLER 

PIC 

X(20) 

VALUE 

'AS IGNOIPD". 

135700 

03 


EILLER 

PIC 

X(20) 

VALUE 

'TOR IGNORED". 

135900 

03 


EILLER 

PIC 

X(20) 

VALUE 

'NOT-PlECOGNI SED " . 

136100 

03 


EILLER 

PIC 

X(20) 

VALUE 

"DEGIN-ASSUMBD". 

1 36300 

03 


PTT.T.-RT? 

PEC 

l(2C) 

VA,LUE 


136500 

02 : 

ER-2 

REDEEINES 

EE-1 . 



1 36700 

03 

ER-3 

OCCURS 14 

TIMES PIG 

X(20). 


136900 PROCEDURE DIVISION. 

137100 USER SECITIOU. 

137300 OPM-EILES. 

137500 OPEN INPUT REPSPC OUTPUT DTNEED. 

137700 MOVE 'REPORT-AN/iYSIS" TO TEXT-OUT. 

137900 PHIEOEM rmiTE-LINE THRU USER-EXIT. 

I 3 &IOO GO TO USER-EXIT. 

138300 READ-LINE. IE TEXT NOT = "OVER" THEN 

138300 RE/iD REPSPC INTO TEXT A.T ElU) MOVE "OVER" TO TEXT. 

138'^00 GO TO USER-EXIT. 

138900 URITE-LINE. 

139^.00* 

139300 ’’7ECTE OUT-REC ESOII TEXT-OUT AETER 2. MOVE SPADES TO TEXT-OUT. 

139500 MOVE SPACES TO OUT-REC. 

139'~00 DUM-1, 

139900 GO TO US.GR-EXIT. 

1 401 00 ERROR-ROUTINE . 

140300 MOVE PAR/'JETER-I TO I. 

140500 MOVE ER-3 (l ) TO iiRE/il . 

140700 MOVE ENTITY TO 

140900 PEREORM mTE-LINE-l . 

Ml 100 GO TO USER-EXIT. 

1 41 300 ERROR-TERMINATE . 

141500 GO TO CLOSE-PARA. 

141700 M/iTCH-DI. 

141900 MOVE 1 TO I. MOVE ZERO TO SU11 J. 

142100 M/iICH-DI-1. 

142300 IE D-Ni'j;./IE(l) = ENTITY MOVE 1 TO SU1 1 MOVE I TO U 

142500 GO TO liLATC H-DI-EXIT . 

142700 IE I = C-SN GO TO ILATCH-DI-EXIT. 

142900 ADD 1 to I. GO TO MATCII-DI-I. 

143100 j'l/.TCH-DI-EXIT. 

143300 EXIT. 



1.'’r3500 WiTCH-DI-EXII'-l . 

143700 GO TO USER-EXIT. 

143900 VffiITE-LIHE-1 . 

1451CJ YffilTE OUT-REC AETER 2. 

144300 MOVE SPACES TO OUT-EEO. 

144500 ENTER-DI. 

144700 ADD 1 TO C-SN. 

144900 MOVE ENTITY TO D-lIAJffl(C-SlT), C-NAME. 

145100 MOVE G-SN TO D-SN(C-SIT). 

145300 MOVE C-LEVEL TO D-IEVEI.(C-SIT) . 

145500 MOVE C-ITEXT-POS TO P-H-POS(C-SN). 

145700 MOVE C-llEXT-POS-APT-DI-NO TO D-N-POS-PI (C-SN ) . 

145900 MOVE C-SN TO C-EEXT-POS-AET-DI-lIO . 

146100 MOVE 'Y" TO D-TIPE(C-SIY) . 

146300 EMTER-DI-EXIT. 

146500 GO TO USER-EXIT. 

14C700 SAVE-VALUE. 

146900 MOVE EOTITY- VALUE TO SA.VS-VAL. 

14V100 GO TO USER-EXIT. 

14’:300 SAVE-POSITION. 

147500 MOVE INTEGER TO SA.VE-POS. 

147700 GO TO USER-EXIT. 

147900 RESET-POSE TI ON. 

1461 00 MOVE 1 TO C-NEXT-POS. 

146300 MOVE ZERO TO C-NEXT-POS-AiET-LI-NO . 

148300 GO TO USER-EXIT. 

148^00 ElYTER-DI-GENERATED. 

148SOO PERE0R14 HYTER-EI. 

M9100 MOVE "GO” TO D-TYPE(C-SN). 

149300 GO TO USER-EXIT. 

1 495 00 ENTER-PILE-N/iME . 

149700 ADD 1 TO C-SN. 

149900 MOVE ENTITY TO D-NAIIB(C-SIT). 

150^00 MOVE 'E" TO D-TYPE(C-SN) . 

150300 MOTO C-LEVEL TO D-LEVEL(G-SN) . 

150500 GO TO USER-EXIT. 

15 0700 VAELUE-OP-DI, 

15090 c TWFOm M/iTCH-DI THRU I'iLATGH-DI-BXIT. 

151190 MOVE SAVE-VAJj TO D-VAL(j). MOVE "C " TO D-TYPE(j). 
151300 GO TO USER-EXIT. 

151500 PLACE-OP-DI. 

151700 PSIiPORM IL1TCH-DI THRU MTGH-DI-EXIT . 

151900 MOVE SilVE-POS TO D-N-POS(j). 

152100 MOVE ZERO TO D-N-POS-DI ( J ) . 

152300 REt.IOVE-DI . 

15 2*^00 SUBTRAiCT 1 FROM C-SN. 

152900 MOVE D-N;J),IECC-SN) TO G-imSE. 

153100 MOVE 0-SN TO C-NEXT-POS-AET-DI-NO. 

153500 GO TO USER-EXIT. 

153700 INGREASE-LEVEL. 

153900 AIDD 1 TO C-LEVEL. 

154100 GO TO USER-EXIT. 



154300 DECIiMSE-LEVEL. 

154500 SUBTHACT 1 PE CM C-LEVED, 

154700 GO TO USEli-EXIT. 

15^900 DATA-EEED. 

155100 MOYE ''DATA-EEEDS : " TO AEEA1 

155300 PEEP mi TEITE-IINE-1 . 

155500 PAEA-1 . 

155700 PjZEPOPJtf DEEPEST THECJ DEEPEST-END. 

155900 IE DEEPEST-LEVEL = 1 GO TO PAIAI-E ELSE GO TO PAEA-1 . 

156100 DEEPEST. 

156300 MOVE 1 TO I. 

156500 MOVE ZERO TO DEEPEST-LEVEL. 

156700 CSiECK-DEEPEST. 

156900 IE S¥05 = 3 

157100 MOVE D-TAELE(i) TO OUT-EBG PEGEOPiM VEITE-LI11E-1 . 

157300 IE D-TYPE(i) = "G" OR "0" MOVE ZERO TO D-LEVEL (l). 

157500 IE D-LEVEL(i) > DEEPEST-LEVEL THEIV 

157700 MOVE D-LEVEL(i) TO DEEPEST-LEVEL 

157900 MOVE I TO FIRST-DEEPEST. 

158100 IE D-LEVEL(i) = DEEPEST-LEVEL TPIELV 

158300 MOVE I TO LAST-DEEPEST. 

158500 CHEGK-1. 

158700 ADD 1 to I. 

158900 IE I EOT > C-SE GO TO CHECK-DEEPEST. 

159100 EEEEAT-DEEPEST. 

159300 PEREOPl OHCE-DEEPEST THRU OHCE-DEEPEST-EHD. 

159500 IE DEEPgST-LEVEL =1 60 TO DEEPEST-EHD, 

159700 AGAIN. 

159900 SUBTRACT 1 FROM LAST-DEEPEST. 

160100 IE D-LEVEL (last-deepest) = DEEPEST-LEVEL GO TO AGAIN. 
160300 MORE-DEEPEST. 

1605 CO SUBTRACT 1 PROM L/ST-DEEPEST. 

160700 IE LAET-DEEPSST EIRST-DEEPEST GO TO DEEPEST-EHD. 

160900 IE D-LEVEL (LAST-DEEPEST) = DEEPEST-LEVEL THEN 

161100 GO TO REPEAT-DEEPEST. 

161300 GO TO MORE-DEEPiiST, 

161500 DEEPEST-END. 

161700 EXIT. 

101900 ONCE-DEEPEST. 

162100 MOVE DEEPEST-LEVEL TO REL-IV. 

162300 MOVE LAST-DEEPEST 10 I. 

162500 MOVE "RELATION" TO ARSA1 . 

162700 ADD 1 TO REL-NO. MOVE REL-NO TO i\REA2. 

162900 PTREORBjI LRITE-LINE-1 . HO’VE ZERO TO REL-DI-SN. 

163100 IE DEEPEST-LEVEL = 1 ADD 1 TO I 

163300 GO TO PARA-1 2. 

163500* Edl LEVEL 1 A ALL DOMINS ARE KEf DaiAINS. 

163700 MOVE "ATTRIBUTE-DOMAINS" TO /REA1 . PEREORDI URITS-LINE-1 . 
163900 PAR/i-IO. 

164100 ADD 1 TO REL-DI-SN. 

164300 MOVE REL-DI-SN TO AREA1 . MOVE D-NAME(I) TO ARE/i2. 

164500 IE D-TIPE(i) = "E" MOVE "IDENTIEICATI ON-NO " TO AREA3 . 

164700 IE D-IEVEL(i) =-.DEEPEST-LEVEL MOVE ZERO TO D-LEVELCI). 

164900 PEREC1RI.I TRITE-LINE-1. 



165100 iV\Il/x-11 . 

1653C0 SUBTriACT 1 PEai I. 

1S535(? II? D-LEVEL(i) = REL-LY GO TO P;in/s.-10. 

165400 IE I -0-^- 

165500 IE D-LEVIIL(i) = .0 j GO TO p/rji-n. 

165700 SUDTEufiCT 1 EE®! EEIL-IV. 

165900 Pi\IlA-12. IE EEL-IV = ZERO GO TO 

166100 MOYE "KEY-DOMIIJS" TO /iREAl . lEREOM WITE-LIHE-I . 
166300 PARA-13. 

166500 IE EEL-LY = ZERO GO TO REA-14. 

166700 PiiRii-15. 

166900, IP D-LEYE[.(l) = REL-EY GO TO PAIL\-16. 

167100 SUPTEixCT 1 ERai I. 

167300 IE D-IEYE[D(i) EEE-EY MOYE "EEEOR" TO /sEEj^I PEREORIJ 
167500 YEITE-IIEE-I GO TO CL03E-P/JiA. GO TO rARA-15. 

167700 P/iEA-ie. 

167900 PEPuPOai PARA-10 THRU TSEA-1 1 . 

168100 GO TO ElffiA-13. 

168300 PAEA-U. 

168500 EXIT, 

168700 OHCE-DEEPEST-EID- 
168900 EXIT. • 

169100 P;JlUx-2. 

169300 EXIT. 

169500* 

169700 * 

169900 CIOSE-PAE/x. 

170100 MOYE "EKD-OE-JOD" TO ARBA1 . 

1 70300 PEREOEM WRITE-LIIIE-1 . 

170500 CLOSE REPSPC LTHEED, 

170700 STOP RUH. 

170900 EHL-OE-JOB. 



